1 start bit + 8 data bits + 1 stop bit = 10 bits (8 of them are "real" data)
so 115200 * (8/10) = 92160 "real" data
PS: I had the same question quite a time ago ;-)
&y0 wrote on 28/1/2005 3:03 μμ:
> According to customer he connects to COM1 with DTE rate of 112K (what is
> the standard of async rate???). Ok. But ~96K (as it can be seen from flood
> ping result below) is not 112K. Additional bandwidth in 112-96=16K just
> desappears :O) Why?
>
> Router#sh int virtual-access 1 | i rate|drop
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 7940
> Queueing strategy: weighted fair
> Output queue: 64/1000/64/7940 (size/max total/threshold/drops)
> 30 second input rate 91000 bits/sec, 10 packets/sec
> 30 second output rate 124000 bits/sec, 12 packets/sec
> Note customer cant make flood ping so I did it from my router and as I
> understand I must have near equal amount of input traffic to output one.
>
>
>>-----Original Message-----
>>From: Tassos Chatzithomaoglou [mailto:achatz@forthnet.gr]
>>Sent: Friday, January 28, 2005 2:41 PM
>>To: andyo@grass.org.ua
>>Cc: cisco-nas@puck.nether.net
>>Subject: Re: [cisco-nas] 96K availainle bandwidth vs 128K BW
>>on Vi1 bundle consisting of 2 B-channels during 64K
>>Unrestrictet call via ISDN-TA PPP-multilink to 5350 NAS
>>
>>If the ISDN-TA is connected to the user's PC though a serial
>>(115200) port, then this might be "logical".
>>
>>&y0 wrote on 28/1/2005 1:51 ??:
>>
>>>Hi everybody. I have problem while customers places calls
>>
>>to 5350 NAS
>>
>>>via ISDN using ISDN-TA and PPP-multilink. During the call 2
>>
>>B-channels
>>
>>>are bound to Virtual-access interface which parameters then
>>
>>looks like this:
>>
>>>Router#sh int virtual-access 1
>>>Virtual-Access1 is up, line protocol is up
>>> Hardware is Virtual Access interface
>>> MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,
>>> reliability 255/255, txload 1/255, rxload 7/255
>>> Encapsulation PPP, loopback not set
>>> DTR is pulsed for 5 seconds on reset
>>> Time to interface disconnect: idle 3w3d
>>> LCP Open, multilink Open
>>> Open: IPCP
>>> Last input 00:00:00, output never, output hang never
>>> Last clearing of "show interface" counters 02:28:22
>>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total
>>
>>output drops: 0
>>
>>> Queueing strategy: weighted fair
>>> Output queue: 0/1000/64/0 (size/max total/threshold/drops)
>>> Conversations 0/50/256 (active/max active/max total)
>>> Reserved Conversations 0/0 (allocated/max allocated)
>>> Available Bandwidth 96 kilobits/sec
>>> 30 second input rate 4000 bits/sec, 2 packets/sec
>>> 30 second output rate 1000 bits/sec, 1 packets/sec
>>> 32892 packets input, 15179159 bytes, 0 no buffer
>>> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>>> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>>> 31164 packets output, 18584822 bytes, 0 underruns
>>> 0 output errors, 0 collisions, 0 interface resets
>>> 0 output buffer failures, 0 output buffers swapped out
>>> 0 carrier transitions
>>>Router#sy
>>> Interface User Mode Idle
>>
>> Peer Address
>>
>>> Vi1 fim Virtual PPP (Bundle) 00:00:06 10.2.2.1
>>> Se3/0:1 fim Sync PPP -
>>
>>Bundle: Vi1
>>
>>> Se3/0:2 fim Sync PPP -
>>
>>Bundle: Vi1
>>
>>>Accordingly customer can obtain the data transfer speed no
>>
>>more ~88K.
>>
>>>It looks like 16K is spent for unknown reason per each B-channel as
>>>arithmetic of 2*(64K-16K)=96K shows I have ever trusted that
>>>signalling bandwidth should be taken from D-channel
>>
>>bandwidth (in my
>>
>>>case Serial3/0:15).
>>>Am I correct? Have anybody solution for this problem? Below is
>>>configuration of ISDN and D-channel isdn switch-type primary-net5
>>>controller E1 3/0 framing NO-CRC4 pri-group timeslots 1-31
>>
>>interface
>>
>>>Serial3/0:15 ip unnumbered FastEthernet0/0 ip nat inside
>>>encapsulation ppp load-interval 30 dialer idle-timeout 2147483
>>>dialer load-threshold 1 outbound dialer-group 1 autodetect
>>>encapsulation ppp v120 isdn switch-type
>>>primary-net5 isdn incoming-voice modem isdn
>>
>>sending-complete no cdp
>>
>>>enable ppp authentication pap contract_tac ppp authorization
>>>contract_tac ppp multilink ppp timeout multilink link add 1
>>>
>>>--
>>>AO618-RIPE
>>>108248909
>>>
>>>_______________________________________________
>>>cisco-nas mailing list
>>>cisco-nas@puck.nether.net
>>>https://puck.nether.net/mailman/listinfo/cisco-nas
>>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas
so 115200 * (8/10) = 92160 "real" data
PS: I had the same question quite a time ago ;-)
&y0 wrote on 28/1/2005 3:03 μμ:
> According to customer he connects to COM1 with DTE rate of 112K (what is
> the standard of async rate???). Ok. But ~96K (as it can be seen from flood
> ping result below) is not 112K. Additional bandwidth in 112-96=16K just
> desappears :O) Why?
>
> Router#sh int virtual-access 1 | i rate|drop
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 7940
> Queueing strategy: weighted fair
> Output queue: 64/1000/64/7940 (size/max total/threshold/drops)
> 30 second input rate 91000 bits/sec, 10 packets/sec
> 30 second output rate 124000 bits/sec, 12 packets/sec
> Note customer cant make flood ping so I did it from my router and as I
> understand I must have near equal amount of input traffic to output one.
>
>
>>-----Original Message-----
>>From: Tassos Chatzithomaoglou [mailto:achatz@forthnet.gr]
>>Sent: Friday, January 28, 2005 2:41 PM
>>To: andyo@grass.org.ua
>>Cc: cisco-nas@puck.nether.net
>>Subject: Re: [cisco-nas] 96K availainle bandwidth vs 128K BW
>>on Vi1 bundle consisting of 2 B-channels during 64K
>>Unrestrictet call via ISDN-TA PPP-multilink to 5350 NAS
>>
>>If the ISDN-TA is connected to the user's PC though a serial
>>(115200) port, then this might be "logical".
>>
>>&y0 wrote on 28/1/2005 1:51 ??:
>>
>>>Hi everybody. I have problem while customers places calls
>>
>>to 5350 NAS
>>
>>>via ISDN using ISDN-TA and PPP-multilink. During the call 2
>>
>>B-channels
>>
>>>are bound to Virtual-access interface which parameters then
>>
>>looks like this:
>>
>>>Router#sh int virtual-access 1
>>>Virtual-Access1 is up, line protocol is up
>>> Hardware is Virtual Access interface
>>> MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,
>>> reliability 255/255, txload 1/255, rxload 7/255
>>> Encapsulation PPP, loopback not set
>>> DTR is pulsed for 5 seconds on reset
>>> Time to interface disconnect: idle 3w3d
>>> LCP Open, multilink Open
>>> Open: IPCP
>>> Last input 00:00:00, output never, output hang never
>>> Last clearing of "show interface" counters 02:28:22
>>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total
>>
>>output drops: 0
>>
>>> Queueing strategy: weighted fair
>>> Output queue: 0/1000/64/0 (size/max total/threshold/drops)
>>> Conversations 0/50/256 (active/max active/max total)
>>> Reserved Conversations 0/0 (allocated/max allocated)
>>> Available Bandwidth 96 kilobits/sec
>>> 30 second input rate 4000 bits/sec, 2 packets/sec
>>> 30 second output rate 1000 bits/sec, 1 packets/sec
>>> 32892 packets input, 15179159 bytes, 0 no buffer
>>> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>>> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>>> 31164 packets output, 18584822 bytes, 0 underruns
>>> 0 output errors, 0 collisions, 0 interface resets
>>> 0 output buffer failures, 0 output buffers swapped out
>>> 0 carrier transitions
>>>Router#sy
>>> Interface User Mode Idle
>>
>> Peer Address
>>
>>> Vi1 fim Virtual PPP (Bundle) 00:00:06 10.2.2.1
>>> Se3/0:1 fim Sync PPP -
>>
>>Bundle: Vi1
>>
>>> Se3/0:2 fim Sync PPP -
>>
>>Bundle: Vi1
>>
>>>Accordingly customer can obtain the data transfer speed no
>>
>>more ~88K.
>>
>>>It looks like 16K is spent for unknown reason per each B-channel as
>>>arithmetic of 2*(64K-16K)=96K shows I have ever trusted that
>>>signalling bandwidth should be taken from D-channel
>>
>>bandwidth (in my
>>
>>>case Serial3/0:15).
>>>Am I correct? Have anybody solution for this problem? Below is
>>>configuration of ISDN and D-channel isdn switch-type primary-net5
>>>controller E1 3/0 framing NO-CRC4 pri-group timeslots 1-31
>>
>>interface
>>
>>>Serial3/0:15 ip unnumbered FastEthernet0/0 ip nat inside
>>>encapsulation ppp load-interval 30 dialer idle-timeout 2147483
>>>dialer load-threshold 1 outbound dialer-group 1 autodetect
>>>encapsulation ppp v120 isdn switch-type
>>>primary-net5 isdn incoming-voice modem isdn
>>
>>sending-complete no cdp
>>
>>>enable ppp authentication pap contract_tac ppp authorization
>>>contract_tac ppp multilink ppp timeout multilink link add 1
>>>
>>>--
>>>AO618-RIPE
>>>108248909
>>>
>>>_______________________________________________
>>>cisco-nas mailing list
>>>cisco-nas@puck.nether.net
>>>https://puck.nether.net/mailman/listinfo/cisco-nas
>>
>
> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas