Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Ascend going mad ? (was: Stable code for Max 1800)
> It appears
> that the 1800 uses _one_ BRI as clock source and gets out of sync if other
> BRIs have remarkable swimming away clocks on other BRIs. This causes massive
> packet loss with all upper layer protocols (ping measures show up to 50%
> lost packets). The problem disappears (on upper layers) when PPP link
> compression is disabled, but this is just an observation, no solution.
I am sorry, it is not that I don't believe that you are seeing a problem...
but your explanation doesn't make sense to me.
How can the use of STAC at the network layer have anything to do with
the physical layer's ability to establish sync?
If you really have a clock sync problem then you should be seeing massive
CRC errors and packets (compressed or not) should be having problems.
The fact that you say the "problem disappears" would point away from the
issue being clock sync and more to a bug in the STAC implementation.
In fact, I would expect that using compression should help to reduce the
impact of a clock sync problem since STAC will reduce the size of the packets
and thus should reduce the chance of an error occuring during the transmission
of a single packet.
example: if you have 1 bit error out of every 1000 bits then if your
packets are only 800 bits long, you have a better chance of
sending a packet without an error than if your packets are
1600 bits long.
I can believe there are clock sync problems and I can believe that there
are STAC problems, I just cannot see how the two are related as you report,
such that disabling compression causes the problem to "disappear".
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
Follow-Ups: