On Tue, 15 Nov 2011 08:18:32 -0800, Jeff Liebermann <jeffl@cruzio.com>
wrote:
>
>Incidentally, a test of startup time on my Efficient 4100 DSL modem
>using fping:
>
>> 2011/11/15 08:13:49 : Reply[11] from 63.249.85.1: bytes=32 time=14.9 ms TTL=63
>> 2011/11/15 08:13:50 : Reply[12] from 63.249.85.1: bytes=32 time=13.8 ms TTL=63
>> 2011/11/15 08:13:52 : 63.249.85.1: request timed out
>> 2011/11/15 08:13:53 : 63.249.85.1: request timed out
>(...)
>> 2011/11/15 08:14:21 : 63.249.85.1: request timed out
>> 2011/11/15 08:14:22 : 63.249.85.1: request timed out
>> 2011/11/15 08:14:22 : Reply[42] from 63.249.85.1: bytes=32 time=38.7 ms TTL=63
>> 2011/11/15 08:14:23 : Reply[43] from 63.249.85.1: bytes=32 time=12.8 ms TTL=63
>
>About 32 seconds. Perhaps if you try a different modem...
My time AFTER my netgear has established a connection with the modem:
[Tue Nov 15 16:58:30 2011]:[POE] ppp0 do disconnect
I order modem to disconnect dsl then reconnect (via web interface)
[Tue Nov 15 16:58:30 2011]:[PPP] ipcp down
[Tue Nov 15 16:58:31 2011]:[POE] send PADT(4065)
[Tue Nov 15 16:58:32 2011]:[UPNP] UPnP daemon is stopped
[Tue Nov 15 16:58:33 2011]:[UPNP] UPnP daemon is ready to run
[Tue Nov 15 16:58:33 2011]:[IGMP] forward multicast group
239.255.255.250.
[Tue Nov 15 16:58:40 2011]:[POE] ppp0 do connect
[Tue Nov 15 16:58:40 2011]:[POE] ppp0 connect mode=0
[Tue Nov 15 16:58:41 2011]:[POE] ppp0 start...
[Tue Nov 15 16:58:41 2011]:[POE] ppp0 (VC0) send PADI
[Tue Nov 15 16:58:42 2011]:[POE] ppp0 rcv PADO
[Tue Nov 15 16:58:42 2011]:[POE] Send PADR, Enter PPPOE_SREQ
[Tue Nov 15 16:58:43 2011]:[POE] ppp0 rcv PADS
[Tue Nov 15 16:58:43 2011]:[POE] Enter PPPOE_CONNECTED,
Session_ID=5372
[Tue Nov 15 16:58:44 2011]:[POE] ppp0 do connect
[Tue Nov 15 16:58:44 2011]:[PPP] start lcp stage
[Tue Nov 15 16:58:45 2011]:[PPP] ipcp up
[Tue Nov 15 16:58:45 2011]:[PPP] Got gateway IP XXX.XXX.XXX.XXX
[Tue Nov 15 16:58:46 2011]:[NTP] Sync with ptbtime1.ptb.de
16 seconds .....
Delay has something to do with the DHCP between netgear and
modem. If a connection is already established, it's really fast.
[]'s
As to the max_pcr, I heard everyone in town (small town in
interior of Brazil) had troubles connecting yesterday. Even the local
WISP could not get their connection up. Apparently, I was the only one
with a stable connection, after I altered the max_pcr. No idea if this
was a coincidence. The ISP recommends 2900, I'm at 1660
Googling "max_pcr=2900" no quotes gives me just about every
linux source code for dsl providers ........
Example:
http://www4.informatik.uni-erlangen....horizon.c.html
:)
I also got this:
PCR: Peak Cell Rate (PCR) is the maximum rate at which the
sender can send cells. This parameter may be lower (but not
higher) than the maximum line speed. 1 ATM cell is 53 bytes (424
bits), so a maximum speed of 832 Kbps gives a maximum PCR of 1962
cells/sec. This rate is not guaranteed because it is dependent on the
line speed.
SCR: Sustained Cell Rate (SCR) is the mean cell rate of a bursty,
on-off traffic source that can be sent at the peak rate, and a
parameter for burst-type traffic. SCR may not be greater than the PCR;
the system default is 0 cells/sec.
MBS: Maximum Burst Size (MBS) is the maximum number of cells that can
be sent at the PCR. After MBS is reached, cell rates fall below SCR
until cell rate averages to the SCR again. At this time, more cells
(up to the MBS) can be sent at the PCR again.
CBR is for connections that support constant rates of data
transfer. The only parameter you need to worry about in CBR is
PCR.
UBR is for connections that have variable traffic. The only parameter
you need to worry about in UBR is PCR.
rtVBR is for connections that, while having variable traffic, require
precise timing between traffic source and destination. PCR, SCR and
MBS must all be set for rtVBR.
nrtVBR is for connections that have variable traffic, do not require
precise timing, but still require a set bandwidth availability. PCR,
SCR and MBS must all be set for nrtVBR.
Half OT, question for Jeff 
Linear Mode
