ra 3.0 timerange broken?

[Carter Bullard]

Yes, you are correct on both counts, if you specify only part of
the date, without '*' in a field, it expects that you are asking for
todays value in that field, (this year, this month, this day, etc.....).

The old behavior wildcarded the fields when there wasn't a hit, and
unfortunately, it would eat about 100uSec+ per flow record just to
do the localtime() -> timelocal() conversions needed to wildcard the
day ( i think it worries about daylight savings time adjustments,
and that really takes some cycles).

Now, what I do like about the new method, is that you can
specify if you want the day wildcarded, or the month, etc....
so if you wanted 2-3 every day or the 2nd of any month, the
filter works really well.

But what I don't like is that there isn't a "quick" way to do what
you wanted to do.

If we can come up with a good strategy, I'd be willing to put it
in now.

Carter



On Mar 12, 2009, at 10:30 AM, Jesper Skou Jensen wrote:

> Oh ok, yes both of your examples work.
>
> So let me understand this correct.
>
> When I use "-t 10:01-10:02" it actually searches the current date,  
> like "-t 2009/03/12.10:01-10:02" right?
>
> I was expecting it to just search for that one minute no matter what  
> the date/seconds/whatever was.
>
>
> -- 
>
>  Jesper S. Jensen
> UNI-C - Århus, Danmark
>
>
> Carter Bullard wrote:
>> Hey Jesper,
>> We changed the time range specification in order to improve the
>> performance.  We were taking a huge hit in system time functions
>> trying to wildcard every date test that we were doing.
>> Check the ra.1 man page and see if the time range you are using
>> seems correct.  The example you gave below, if you ran it today,
>> it wouldn't match anything, cause its only 9:54AM here ;o)
>> If you wanted any 10:01-10:02 this month, you could use:
>>   **.10:01-**.10:02
>> or, does this work?
>>   11.10:01-10:02
>> Carter
>> On Mar 12, 2009, at 5:29 AM, Jesper Skou Jensen wrote:
>>> Hi guys,
>>>
>>> I think there is a bug in the 3.0 ra client's timerange.
>>>
>>> I would expect the same output from the two commands below, but  
>>> that's not the case.
>>>
>>> ra -r logfile.gz -t 10:01-10:02
>>> reports no output
>>>
>>> ra -r logfile.gz -t 2009/03/11.10:01-10:02
>>> reports all the sessions as expected
>>>
>>>
>>> -- 
>>>
>>> Jesper S. Jensen
>>> UNI-C - Århus, Danmark
>>>
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E 57th Street Suite 12D
>> New York, New York  10022
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax