Re: Flow timeout value

Re: Flow timeout value

Re: radium

Re: radium

Re: simple ra time filter question...

Hey Poncenby,
Did you get a chance to look into the "-t" option in any more detail?
I'm going to fix it today, and would love to hear all the issues!!!

Carter

On Dec 20, 2006, at 6:27 PM, poncenby smythe wrote:

> what would the command line look like to read an argus file  
> 'argus.data'   and only show records for November 2006?
>
> i've tried this...
>
> ra -r argus.data -t 2006/11
>
> and it errors with 'time syntax error'
>
> i can't understand the -t section of the man ra page at all!
>
> thanks
>
> poncenby
>

Re: radium

Re: simple ra time filter question...

Hey Philipp (and poncenby),
I found a problem in the time parsing, and all seems to be working now.
I'll try to put up new code tomorrow, or later tonight.

> On Wed, Dec 20, 2006 at 11:27:00PM +0000, poncenby smythe wrote:
>> what would the command line look like to read an argus file  
>> 'argus.data'
>>   and only show records for November 2006?

this filter will work with older versions of argus-3.0:
    "-t 2006/11/01+1M"

this will work now with the fixes I put in, and would be a better  
filter:
    "-t 2006/11+1M"

If you only have one "/", it assumed that you were specifying "mm/dd",
which is in the documentation.  Now it will accept "yyyy/mm".

There is some ambiguity on how the time range works, and so
I'll need some help to describe it so that its understandable.  Here's
a start, but more is needed, so if we can get a dialog going, at least
it will be in the mail archive.

There are basically 2 time strategies, explicit and relative time,
and three range comparisons; span, inclusive, and exclusive.

Explicit is specified with two complete time values, (explicit start  
and stop
times with year, month, day, hour, min, and sec specified).   If the  
start time
value is explicit, then the second time will also be explicit, so you  
don't have
to put in the year, in both, as an example (unless you cross a year
boundary, of course :o).  Parsing the two values generates a fixed time
range that is compared against the timestamps in the argus records.

There are two ways to specify a time value; datetime and offset.
A datetime value has a year/month/day.hour:min:sec format, but you
don't have to provide the year, month, day, hour, minute or second
values if they are the same as the current time's values.
Offsets are [-/+] values from the current time, or from a given starting
point.  The format is [-/+] num"smhdMy", where the "smhdMy" stands for
seconds, minutes, hours, days, Months or years.  Offsets always force
the time to be explicit, as they are generally designed to specify a  
range
against the current time, which is an explicit time value.

Examples are:
    "2005/09/11.09:52:41-13:00:03"
    "01/02.23-23:11"
    "01.07:12:29-08:03:55"
    "-12d+5m"
    "2005/09/01+1M"
    "-5m"

However, be cautious with the offset specification.  The filters:
     " -2d+5m "
     " -2d-5m "

are different.  The first is the range "-2 days from now" to start,  
and the
ending time is "+5 minutes" later.  The second is the range "-2 days -
5 minutes" to start, and ends at "-2 days".  This is probably a bad  
thing,
but its the result of having signed values relative to a specified time.
So, for relative ranges, it will be best if you always use the "+"  
operator.

When the time is not completely specified, where the year, month
or day are not specified, then the time range is relative and as a
result, the time filter can match independent of year, month and/or day.

So the filter:
    " 12-14 "

which is 12 noon to 2 PM, will match independent of what day you feed  
the
filter.  So if you run through a weeks worth of data, the time range  
will be
used against Mon, Tues, Wed, etc....  This is great for comparing  
time-of-day
trends and behaviors.  Because there is wildcarding, the performance is
not that good, so try to be explicit in your time range specifications.

The three comparison modes are there to specify how you want to compare
the times.  "Inclusive" is where the record start and stop times  
cover the
timerange.  This is great when you want to know "what flows were active
during this time range", and is invaluable for understanding flows  
that may
be used to control other flows.

"Exclusive" is where both the start and stop times are within the  
timerange.
This is important to find the dependent flows, ie flows that must  
complete
in order for this flow to finish.

"Span" allows for any overlap to match, this is the default.

You specify the type using "ies" as the first character of the time  
specification.

So, if you wanted to find any record that is totally contained within  
the
time range 12:31:15-12:53:16 on Dec 23, 2006:

    -t  x2006/12/23.12:31:15-12:53:16

OK, so if there is any issue with understanding the idea behind time  
filters,
please send some mail to the list!!!!

Carter

On Dec 21, 2006, at 1:33 AM, Philipp E. Letschert wrote:

> On Wed, Dec 20, 2006 at 11:27:00PM +0000, poncenby smythe wrote:
>> what would the command line look like to read an argus file  
>> 'argus.data'
>>   and only show records for November 2006?
>
> ra -r argus.data -t 2006/11/01-2006/11/30
>
> The only drawback, is that you need to know the actual number of  
> days in a month
>
>> i can't understand the -t section of the man ra page at all!
>
> There are three possibilities what a time range could look like
> 1) [[[yyyy/]mm/]dd.]hh[:mm[:ss]]
> 2) [yyyy/]mm/dd
> 3) -%d{yMdhms}
>
> the parameters in square brackets are optional, so for 1)  
> specifying a number
> with 2 digits will always be interpreted as hour, you can expand it  
> to the left
> (by adding dd.) or to the right (by adding :mm).
>
> the second one shows how dates are handled, so you can see that  
> 2006/11 would
> beinterpreted as month/day, the only way to see the whole month is  
> using a range
> with '-'.
>
> the last one is puzzling to me, as I understood it is a offset back  
> in the past,
> so I expected either -1M or -51d-21d to show only records from the  
> last month,
> but this did not work.
>
> Regards, Philipp
>

Re: simple ra time filter question...

Carter Bullard wrote:
> Hey Philipp (and poncenby),
> I found a problem in the time parsing, and all seems to be working now.
> I'll try to put up new code tomorrow, or later tonight.
> 
> 
>> On Wed, Dec 20, 2006 at 11:27:00PM +0000, poncenby smythe wrote:
>>> what would the command line look like to read an argus file 'argus.data'
>>>   and only show records for November 2006?
> 
> this filter will work with older versions of argus-3.0:
>    "-t 2006/11/01+1M"
> 
> this will work now with the fixes I put in, and would be a better filter:
>    "-t 2006/11+1M"

thanks for clearing that up, the second example seems logical as this is 
the method for specifying a range or hours/minutes/seconds.
> 
> If you only have one "/", it assumed that you were specifying "mm/dd",
> which is in the documentation.  Now it will accept "yyyy/mm".

what would the -t value be to filter on all records in November, 
spanning multiple years?

> 
> 
> There is some ambiguity on how the time range works, and so
> I'll need some help to describe it so that its understandable.  Here's
> a start, but more is needed, so if we can get a dialog going, at least
> it will be in the mail archive.
> 
> 
> 
> There are basically 2 time strategies, explicit and relative time,
> and three range comparisons; span, inclusive, and exclusive.
> 
> Explicit is specified with two complete time values, (explicit start and 
> stop
> times with year, month, day, hour, min, and sec specified).   If the 
> start time
> value is explicit, then the second time will also be explicit, so you 
> don't have
> to put in the year, in both, as an example (unless you cross a year
> boundary, of course :o).  Parsing the two values generates a fixed time
> range that is compared against the timestamps in the argus records.
> 
> There are two ways to specify a time value; datetime and offset.
> A datetime value has a year/month/day.hour:min:sec format, but you
> don't have to provide the year, month, day, hour, minute or second
> values if they are the same as the current time's values.
> Offsets are [-/+] values from the current time, or from a given starting
> point.  The format is [-/+] num"smhdMy", where the "smhdMy" stands for
> seconds, minutes, hours, days, Months or years.  Offsets always force
> the time to be explicit, as they are generally designed to specify a range
> against the current time, which is an explicit time value.
> 
> Examples are:
>    "2005/09/11.09:52:41-13:00:03"
>    "01/02.23-23:11"
>    "01.07:12:29-08:03:55"
>    "-12d+5m"
>    "2005/09/01+1M"
>    "-5m"
> 
> However, be cautious with the offset specification.  The filters:
>     " -2d+5m "
>     " -2d-5m "
> 
> are different.  The first is the range "-2 days from now" to start, and the
> ending time is "+5 minutes" later.  The second is the range "-2 days -
> 5 minutes" to start, and ends at "-2 days".  This is probably a bad thing,
> but its the result of having signed values relative to a specified time.
> So, for relative ranges, it will be best if you always use the "+" 
> operator.
> 
> When the time is not completely specified, where the year, month
> or day are not specified, then the time range is relative and as a
> result, the time filter can match independent of year, month and/or day.
> 
> So the filter:
>    " 12-14 "
> 
> which is 12 noon to 2 PM, will match independent of what day you feed the
> filter.  So if you run through a weeks worth of data, the time range 
> will be
> used against Mon, Tues, Wed, etc....  This is great for comparing 
> time-of-day
> trends and behaviors.  Because there is wildcarding, the performance is
> not that good, so try to be explicit in your time range specifications.
> 
> The three comparison modes are there to specify how you want to compare
> the times.  "Inclusive" is where the record start and stop times cover the
> timerange.  This is great when you want to know "what flows were active
> during this time range", and is invaluable for understanding flows that may
> be used to control other flows.
> 
> "Exclusive" is where both the start and stop times are within the 
> timerange.
> This is important to find the dependent flows, ie flows that must complete
> in order for this flow to finish.
> 
> "Span" allows for any overlap to match, this is the default.
> 
> You specify the type using "ies" as the first character of the time 
> specification.

not sure what "ies" means, the letter 'x' is the first character in the 
example below

> 
> So, if you wanted to find any record that is totally contained within the
> time range 12:31:15-12:53:16 on Dec 23, 2006:
> 
>    -t  x2006/12/23.12:31:15-12:53:16
> 
> 
> OK, so if there is any issue with understanding the idea behind time 
> filters,
> please send some mail to the list!!!!

apart from the comments above, clear as crystal!

> Carter
> 
> 
> 
> 
> 
> On Dec 21, 2006, at 1:33 AM, Philipp E. Letschert wrote:
> 
>> On Wed, Dec 20, 2006 at 11:27:00PM +0000, poncenby smythe wrote:
>>> what would the command line look like to read an argus file 'argus.data'
>>>   and only show records for November 2006?
>>
>> ra -r argus.data -t 2006/11/01-2006/11/30
>>
>> The only drawback, is that you need to know the actual number of days 
>> in a month
>>
>>> i can't understand the -t section of the man ra page at all!
>>
>> There are three possibilities what a time range could look like
>> 1) [[[yyyy/]mm/]dd.]hh[:mm[:ss]]
>> 2) [yyyy/]mm/dd
>> 3) -%d{yMdhms}
>>
>> the parameters in square brackets are optional, so for 1) specifying a 
>> number
>> with 2 digits will always be interpreted as hour, you can expand it to 
>> the left
>> (by adding dd.) or to the right (by adding :mm).
>>
>> the second one shows how dates are handled, so you can see that 
>> 2006/11 would
>> beinterpreted as month/day, the only way to see the whole month is 
>> using a range
>> with '-'.
>>
>> the last one is puzzling to me, as I understood it is a offset back in 
>> the past,
>> so I expected either -1M or -51d-21d to show only records from the 
>> last month,
>> but this did not work.
>>
>> Regards, Philipp
>>
> 
> 
> 
> ===========================================================
> This email has been verified as Virus free
> Virus Protection and more available at http://www.plus.net
> ===========================================================
> 
> ===========================================================
> This email has been verified as Virus free
> Virus Protection and more available at http://www.plus.net
> ===========================================================
> 

xbox 360 game performance analysis

Gentle people,
I am starting a little project to analyze the behavior of an Xbox 360  
while
its doing its multiplayer server/client gaming thing.  Are there any  
gamers
in the group that have an interest in helping to quantify game network
performance?  I personally like games like Call of Duty, and I've  
dabbled
only briefly with Halo 2, so I'm probably not the one to pick the  
game.  If
we do something reasonable, we could take it to one of these mega-gaming
conferences and do some analysis.

Xbox 360 because I have one, but if/when a PS3 is available, we could do
that as well.   If the PS2 has significant network capability, we  
could so
somthing there, if there is a compelling game to analyze.

The main challenge is finding a measurement strategy that is  
meaningful to
the gamer, but also meaningful for the ISP who needs to support a  
level of
QoS to keep the gamer subscriber.  Server availability, RTT and Loss  
statistics,
MTU mismatches, TCP window parameters (assuming TCP is being used) all
have an impact.   Things like peak demand vs availability is pretty  
easy to
measure as long as the game is using trackable protocols, and of  
course if
the game uses multicast, we've got a good monitoring strategy for  
distributed
multicast performance.

Its a pretty good project to think about, or at least to talk about!!!!

Carter

Re: radium