Feature #5667
closedTest different PM3 for ZModem throughput
Added by laforge over 1 year ago. Updated over 1 year ago.
100%
Description
We've observed very strange low ZModem throughput on the PM3 currently used in the OCTOI setup (with any of the tcp/telnet forwarding). jolly had observed good throughtput with a PM4 and as far as I remember somebody else also has shown proper througput on their PM3.
as I have 3 PM3 currently at my home: Compare and see if there's any difference; if there is, make sure that a unit with good throughput ends up in the co-location (see #5542)
Related issues
Updated by laforge over 1 year ago
- Related to Bug #5542: Move hub to datacenter colocation added
Updated by laforge over 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
did the [hopefully sufficient] configuration of PM3-2 (my third PM3, from monaco telecom) last night.
Some of the original config, out of curiosity:
Livingston Enterprises, Inc. Boot Prom Rev P
Testing Low Memory....
Checking Boot Rom....
Testing System Clock....
Sizing System Memory... 4MB
CPU Type.... 486DE2-66
Starting FLASH Boot.....
Booting From Flash Type Am29F040
16384 flash copy complete
Verifying Loader Module Checksum...
Starting Loader ...
Scheduler Process:
Loading kernel... 1280840 bytes
Testing High Memory ... . 4096K
munich_init_device: NO DEVICE 1
Found 31 ports....
ether0 active ... 64K burst-IO
Running ComOS...
PortMaster Console login: !root
Password:
CHALLENGE: 3F7=F8PDKWYQFABA
Invalid Login
PortMaster Console login: <KVS3>O>CM2WM7A:
Password:
Invalid Login
PortMaster Console login: !root
Password:
titan4a> version
Lucent PortMaster PM-3 ComOS 3.9.1c1
System uptime is 1 minutes
titan4a> set password foobar
!root password changed from zee9 to foobar
titan4a> show glo
System Name: titan4a
Default Host: 0.0.0.0
Alternate Hosts:
IP Gateway: 194.51.26.254
Gateway Metric: 1
Default Routing: Quiet (Off)
Name Service: DNS
Name Server: 194.51.26.1, 194.51.26.2
Domain: monaco.mc
Telnet Access Port: 23
Loghost: 212.234.168.7
Maximum PMconsole: 1
Assigned Address: 194.51.26.225 (Pool Size 20)
RADIUS Server: 212.234.168.7* 1645
Alternate Server: 194.51.26.6 1645
Accounting Server: 212.234.168.7 1646
Alt. Acct. Server: 194.51.26.6 1646
Acct Retry Interval: 30 Sec
Acct Retry Count: 6
Auth Retry Interval: 0 Sec
Auth Failover: off
ChoiceNet Server: 0.0.0.0
Alt. ChNet Server: 0.0.0.0
PPP Authentication: PAP: on CHAP: on
ISDN Switch Type: etsi
End Point Disc: None
Disabled Modules: SNMP OSPF L2TP BGP
titan4a> show netco
Hnd Recv-Q Send-Q Local Address Foreign Address (state)
8 0 0 194.51.26.224.67 0.0.0.0.0 UDP
7 0 0 194.51.26.224.23 0.0.0.0.0 LISTEN
6 0 0 194.51.26.224.1643 0.0.0.0.0 LISTEN
5 0 0 194.51.26.224.1026 194.51.26.6.1646 UDP
4 0 0 194.51.26.224.1023 212.234.168.7.514 UDP
3 0 44 194.51.26.224.1025 194.51.26.1.53 UDP
1 0 0 194.51.26.224.520 0.0.0.0.0 UDP
titan4a> show files
File Name Length
---------------- -------
confdata 15713
config 218
snmp 21
hfile 47275
m2d_2.2 86810 (262144 uncompressed)
m2c_2.2 22749 (74070 uncompressed)
wanctl.0 9951 (40746 uncompressed)
mipsboot 23363 (65988 uncompressed)
-------
Total 206100
titan4a> show ospf
OSPF is not active
titan4a> show syslog
Syslog Configuration Settings
admin-logins: auth.info
user-logins: auth.info
packet-filters: auth.notice
commands: disabled
termination: disabled
nat: disabled
ipsec: disabled
titan4a> show modems
Mdm Port Status Speed Compression Protocol Calls Retrain Disconnect
--- ---- ------ ----- ----------- -------- ------ ------- ------------
M20 READY UNKNWN NONE NONE 0 0 NORMAL
M21 READY UNKNWN NONE NONE 0 0 NORMAL
M22 READY UNKNWN NONE NONE 0 0 NORMAL
M23 READY UNKNWN NONE NONE 0 0 NORMAL
M24 READY UNKNWN NONE NONE 0 0 NORMAL
M25 READY UNKNWN NONE NONE 0 0 NORMAL
M26 READY UNKNWN NONE NONE 0 0 NORMAL
M27 READY UNKNWN NONE NONE 0 0 NORMAL
M28 READY UNKNWN NONE NONE 0 0 NORMAL
M29 READY UNKNWN NONE NONE 0 0 NORMAL
titan4a> show hosts
Host Internet Addr: 0.0.0.0
Gateways: Default: 194.51.26.254
titan4a> show isdn
D Ports State L1 L2 Change init Up Down
-- ------- ------------- ------- ----- ----- -----
0 S0-S29 DOWN Inactive 7 0 0 0
1 Not configured for PRI
titan4a> show routes
Destination Mask Gateway Source Flag Met Interface
----------------- ---- -------------------- ------- ---- --- ---------
0.0.0.0 0 194.51.26.254 local NS 1 ether0
194.51.26.192 26 194.51.26.224 local NL 1 ether0
titan4a> show ether0
Ethernet Status: IP - Enabled IPX - Disabled
Interface Addr: 194.51.26.224
Netmask: 255.255.255.192
Broadcast Address: 194.51.26.255
IPX Network: 00000000
IPX Frame Type: ETHERNET_802.2
Ethernet Address: 00:c0:05:04:59:dc
Routing: RIP(Broadcast, Listen (On))
Input Filter:
Output Filter:
Configuration is to allow it tobe placed in the same iP network as the pm3-lrw34a currently used by OCTOI:
pm3-2> show global
System Name: pm3-2
Default Host: 0.0.0.0
Alternate Hosts:
IP Gateway: 192.168.7.254
Gateway Metric: 1
Default Routing: Quiet (Off)
Name Service: DNS
Name Server: 192.168.7.2
Domain: retronetworking.org
Telnet Access Port: 23
Loghost: 192.168.7.2
Maximum PMconsole: 1
Assigned Address: 0.0.0.0
RADIUS Server: 192.168.7.2* 1813
Alternate Server: 0.0.0.0
Accounting Server: 192.168.7.2 1812
Alt. Acct. Server: 0.0.0.0
Acct Retry Interval: 30 Sec
Acct Retry Count: 6
Auth Retry Interval: 0 Sec
Auth Failover: off
ChoiceNet Server: 0.0.0.0
Alt. ChNet Server: 0.0.0.0
PPP Authentication: PAP: on CHAP: on
ISDN Switch Type: etsi (Call Check Enabled)
L2TP LAC
ISDN numberplan: ISDN E.164
ISDN numbertype: Local
End Point Disc: None
Disabled Modules: SNMP IPX OSPF BGP
pm3-2> exit
Updated by laforge over 1 year ago
Ok, so I now have the following setup:
- client side:
- minicom
- USB-RS232 converter
- US_Robotics_Sportster_ISDN_TA_Ext
- network side:
- Auerswald COMmander Basic 2 (to go from BRI to PRI)
- TE820 with yate as softswitch
- server side:
- 2x Livingston Portmaster3 attached via E1
- using tcp-clear forwarding to a remote telnet server, serving random bytes
- 2x Livingston Portmaster3 attached via E1
The old random ZModem number is 030-1234-3005, the new PM3 random ZModem number is 030-1234-5005
When I make a data call with X.75 or V.120 to either of the two PM3, I'm getting about 2200 cps, which is abysimal. It should be around 7000.
The good news is that both PM3 behave identical, so it's not a hardware issue with either of them.
The question remains: why is it so slow?
Maybe it's something on the client side? Guess I need to bring on more ISDN TA.
Updated by manawyrm over 1 year ago
Maybe it's something on the client side? Guess I need to bring on more ISDN TA.
Hm, I don't think so. I've seen this with both my AVM ISDN Stack on Windows and ELSA MicroLink isdn TA.
As L2TP is fast -- could we somehow isolate if maybe the network stack / TCP implementation in the PM3 is bad? Are there some other ways to input data, like an RS232 port or something?
Updated by laforge over 1 year ago
- The DTE rate between TA and minicom is 115200 bps
- There is no hardware or software flow control enabled
- Enabling hardware flow control doesn't improve the situation
- Most testing was done with a PL2303 USB-serial IC; switching to a FT232RL doesn't change the low throughput.
Updated by laforge over 1 year ago
manawyrm wrote in #note-4:
Maybe it's something on the client side? Guess I need to bring on more ISDN TA.
Hm, I don't think so. I've seen this with both my AVM ISDN Stack on Windows and ELSA MicroLink isdn TA.
remote over OCTOI or locally at the last CCC congress?
As L2TP is fast -- could we somehow isolate if maybe the network stack / TCP implementation in the PM3 is bad? Are there some other ways to input data, like an RS232 port or something?
no, I don't think therer is any way. I'd really like to know what's going on, especially since there were reports from other people who didn't have that problem, AFAIR.
For ISDN (X.75/V.120) it should be "relatively easy" to write a functionally equivalent open source replacement for the PM3. Use a Q.931 library for the signaling side and get X.75 and V.120 implemented. That's my mid-term strategy anyway. For the analog modems it's of course harder, as we'd need a proper softmodem implementation for the various relevant standards first, which is a separate, comprehensive project in itself.
Updated by laforge over 1 year ago
- % Done changed from 10 to 40
looking at the IRC logs, it seems like the higher CPS rates were only reported with other equipment (Ascend Max, Portmaster 4), but not with PM3.
I also recall having looked at the tcpdumps in the past and did not see anything odd there, either.
The context of this ticket was to compare multiple PM3, and I've now just done that: At least those two out of three I tested are comparable poor in "login" type use cases.
Updated by manawyrm over 1 year ago
Those tests were done remote over OCTOI. Communication between 2 machines on OCTOI via X.75 (without a PM3 involved) works at the full 7xxx bytes/second, which is why I figured that this test should be fine to do remotely.
Doing X.75 and V.120 in software sounds like a very good idea. Maybe the idea by supersat done for https://github.com/Shadytel/shadysoftmodem (operating as an external script in YATE) would be a good idea for terminating data calls?
Could skip all the Q.931 handling and just focus on the X.75 for the time being.
shadysoftmodem is also very promising (even if it can't do V.90 in answer mode), but it's a i386 closed software blob after all, so really not ideal.
(this discussion is probably better done somewhere else, maybe in another ticket :D)
Updated by laforge over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 40 to 100
I've now tested all my three PM3 in different configurations: With and without radius call-check; locally in my basemenet with no TDMoIP and remote. The CPS for ISDN X.75/V.120 is always abysimal around 3900cps, no matter if telnet or tcp-clear are used. The TCP socket is using SO_NODELAY, so that's not the problem.
I looked at the raw B channels occasionally and it just looks like there are long pauses (flag octets) between actual HDLC frames.
So I guess we can conclude that the PM3 is really not a good device for achieving full throughput when using telnet/tcp-clear forwarding.
