[ntp:questions] Re: Known asymmetry (DSL) compensation

John Pettitt jpp at cloudview.com
Tue Feb 15 17:41:11 UTC 2005


Jan Ceuleers wrote:

>On Mon, 14 Feb 2005 18:25:14 GMT, John Pettitt <jpp at cloudview.com>
>wrote:
>
>  
>
>>I know it's not possible to know or compensate for all asymmetry in the 
>>packets between two machines.  However where there is a fixed, known, 
>>asymmetry - like on a DSL line shouldn't it be possible to calculate a 
>>fudge factor?
>>    
>>
>
>The problem with defining a fixed "correction" for this is the
>following:
>
>What you want to correct is the difference in latency in the upstream
>vs. downstream directions. The trouble is that this cannot be readily
>calculated from any known and constant values, such as the upstream
>and downstream bitrates.
>
>Whereas you would expect that the uplink (from the CPE to the DSLAM)
>would have higher latency due to the lower bitrate, upstream traffic
>deeper in the network (DSLAM-BRAS and BRAS-Internet) generally uses
>less-loaded links than those in the downstream direction. It is
>impossible to know whether the latter (more than) compensates for the
>former.
>
>Moreover, the upstream latency between CPE and DSLAM is very dependent
>on the offered upstream traffic (in other words: whether upstream
>packets sit in a queue in the CPE before being forwarded onto the
>line, or whether upstream traffic is low enough to be able to be
>forwarded immediately).
>
>
>  
>
I understand that the overall asymmetry is not knowable with any
certainty - however there is a baseline asymmetry derived from the bit
rates that is knowable and I'd like to at least factor that out.  Think
of it factoring out the propagation delay on a radio clock - while it's
not the only error in the system it's one I can know and correct for.
I'm willing to live with the errors cause by traffic levels - those are
variable - it's the systemic, fixed, error I want to tune out.

So a I renew my question is there somebody on the list who is willing to
have an off list conversation about ntp internals to get me up to speed
on what I need to do (I spent 5 years writing unix device drivers and
another 5 writing fraud detection software - I'm up to the programming
but would rather not have to deconstruct the ntpd source to figure out
what it's doing).


John







More information about the questions mailing list