On 4/13/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
Quoting Arnaldo Carvalho de Melo:
| On 4/2/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
| > | > [DCCP]: Cheaper & smaller timestamping
| >
| > | A couple of comments though:
| > | - this is how I had the code originally in many cases and Arnaldo
| > | changed - can't remember why.
| > Arnaldo's code uses a reference point, the skb_get_timestamp() also did
| > that. May be useful against old incarnations across reboots.
|
| I got to this cset now in today's merge session, the cset that did that was:
|
| b0e567806d16586629468c824dfb2e71155df7da
|
| Comment was, unfortunately, not so clear:
|
| ----
| [EMAIL PROTECTED] net-2.6.22]$ git-show
b0e567806d16586629468c824dfb2e71155df7da
| commit b0e567806d16586629468c824dfb2e71155df7da
| Author: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
| Date: Fri Sep 9 02:38:35 2005 -0300
|
| [DCCP] Introduce dccp_timestamp
|
| To start the timestamps with 0.0ms, easing the integer maths in
| the CCIDs, this
| probably will be reworked to use the to be introduced struct timeval_offset
| infrastructure out of skb_get_timestamp, etc.
|
| Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
| ---
|
| What are the architectures you've been testing? All 64 bits? IIRC the
| problem was related to overflows, suseconds_t is unsigned long, so 32
| bits on i386...
I have tested on various i386 instances (where it is `long') and on sparc64
(where it is `int', as
in parisc). I was just calculating - there is indeed a chance to produce
overflow, since we add
in timeval_add_usecs (since it is a signed type, the same problem seems to
reappear in timeval_sub_usecs).
I don't have accurate figures at the moment with regard to overflow, but I
assume that it is better to revert
this patch?
There is a related question - with the new timesystem, should we convert to
__get_realtime_clock_ts(), as
the comment above do_gettimeofday() says in kernel/timer.c ?
I would be glad for clarification, since there are quite a few patches to
update.
I'd say leave the dccp_timestamp alone for now, I have to read a bit
more on the new time system and what was done on the net schedulers,
etc before being able to say something meaningful on this aspect.
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html