Tim Sowden(deleted)
|
QNX 7 E1000 Driver Very Slow Sending Only
|
Tim Sowden(deleted)
01/19/2018 6:22 PM
post118417
|
QNX 7 E1000 Driver Very Slow Sending Only
I have a QNX 7 machine with dual Intel NIC cards in it only 1 of which is plugged in.
Transferring files from this machine is incredibly slow but sending files is lightning fast. I have another older QNX 6
machine (different NIC hardware) on the same network and transferring files in both directions is fine.
QNX 6 Machine:
C:\Users\admin\transfer>ftp 172.27.12.103
Connected to 172.27.12.103.
220 172.27.12.103 FTP server ready.
502 Unknown command UTF8.
User (172.27.12.103:(none)): root
331 Password required for root.
Password:
230-
Welcome to QNX Neutrino!
230 User root logged in.
ftp> bin
200 Type set to I.
ftp> put deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core'.
226 Transfer complete.
ftp: 11628544 bytes sent in 0.38Seconds 31009.45Kbytes/sec.
ftp> get deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core' (11628544 bytes).
226 Transfer complete.
ftp: 11628544 bytes received in 0.66Seconds 17726.44Kbytes/sec.
ftp>
QNX 7 machine
C:\Users\admin\transfer>ftp 172.27.12.3
Connected to 172.27.12.3.
220 172.27.12.3 FTP server (QNXNTO-ftpd 20081216) ready.
502 Unknown command 'UTF8'.
User (172.27.12.3:(none)): qnxuser
331 User qnxuser accepted, provide password for qnxuser@SurfaceController.
Password:
230-No directory! Logging in with home=/
230 User qnxuser logged in.
ftp> cd /tmp
250 CWD command successful.
ftp> bin
200 Type set to I.
ftp> put deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core'.
226 Transfer complete.
ftp: 11628544 bytes sent in 0.38Seconds 31009.45Kbytes/sec.
ftp> get deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core' (11628544 bytes).
226 Transfer complete.
ftp: 11628544 bytes received in 73.31Seconds 158.62Kbytes/sec.
ftp>
Note that incredibly slow transfer rate!
I start networking to use just 1 NIC with a static IP
io-pkt-v6-hc -d e1000 &
if_up -r 10 -p wm1
ifconfig wm0 up
ifconfig wm1 172.27.12.3 up
inetd &
Ifconfig reports:
# ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>
capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>
enabled=0
address: 00:0b:ab:d6:bd:15
media: Ethernet none
inet6 fe80::20b:abff:fed6:bd15%wm0 prefixlen 64 scopeid 0x11
wm1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>
capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>
enabled=0
address: 00:0b:ab:d6:bd:16
media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause)
status: active
inet 172.27.12.3 netmask 0xffff0000 broadcast 172.27.255.255
inet6 fe80::20b:abff:fed6:bd16%wm1 prefixlen 64 scopeid 0x12
Nicinfo looks fine (gigabit, full duplex, no physical medium errors)
# nicinfo
wm0:
INTEL PRO/1000 Gigabit (Copper) Ethernet Controller
Link is DOWN
Physical Node ID ........................... 000BAB D6BD15
Current Physical Node ID ................... 000BAB D6BD15
Current Operation Rate ..................... Unknown
Active Interface Type ...................... MII
Active PHY address ....................... 2
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 1500
Hardware Interrupt ......................... 0x102
Memory Aperture...
View Full Message
|
|
|
Hugh Brown
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Hugh Brown
01/22/2018 8:10 AM
post118419
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
The QNX6 and QNX7 e1000 drivers should be identical, so I don't know why you are having the slowdown on the QNX7 machine
. Can you run QNX6 on that machine and see if the driver behaves the same? Also, please post the output from "pci-tool -
vv" from the QNX7 machine.
Thanks, Hugh.
On 2018-01-19, 6:01 PM, "Tim Sowden(deleted)" <community-noreply@qnx.com> wrote:
I have a QNX 7 machine with dual Intel NIC cards in it only 1 of which is plugged in.
Transferring files from this machine is incredibly slow but sending files is lightning fast. I have another older
QNX 6 machine (different NIC hardware) on the same network and transferring files in both directions is fine.
QNX 6 Machine:
C:\Users\admin\transfer>ftp 172.27.12.103
Connected to 172.27.12.103.
220 172.27.12.103 FTP server ready.
502 Unknown command UTF8.
User (172.27.12.103:(none)): root
331 Password required for root.
Password:
230-
Welcome to QNX Neutrino!
230 User root logged in.
ftp> bin
200 Type set to I.
ftp> put deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core'.
226 Transfer complete.
ftp: 11628544 bytes sent in 0.38Seconds 31009.45Kbytes/sec.
ftp> get deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core' (11628544 bytes).
226 Transfer complete.
ftp: 11628544 bytes received in 0.66Seconds 17726.44Kbytes/sec.
ftp>
QNX 7 machine
C:\Users\admin\transfer>ftp 172.27.12.3
Connected to 172.27.12.3.
220 172.27.12.3 FTP server (QNXNTO-ftpd 20081216) ready.
502 Unknown command 'UTF8'.
User (172.27.12.3:(none)): qnxuser
331 User qnxuser accepted, provide password for qnxuser@SurfaceController.
Password:
230-No directory! Logging in with home=/
230 User qnxuser logged in.
ftp> cd /tmp
250 CWD command successful.
ftp> bin
200 Type set to I.
ftp> put deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core'.
226 Transfer complete.
ftp: 11628544 bytes sent in 0.38Seconds 31009.45Kbytes/sec.
ftp> get deviceMgr.core
200 PORT command successful.
150 Opening BINARY mode data connection for 'deviceMgr.core' (11628544 bytes).
226 Transfer complete.
ftp: 11628544 bytes received in 73.31Seconds 158.62Kbytes/sec.
ftp>
Note that incredibly slow transfer rate!
I start networking to use just 1 NIC with a static IP
io-pkt-v6-hc -d e1000 &
if_up -r 10 -p wm1
ifconfig wm0 up
ifconfig wm1 172.27.12.3 up
inetd &
Ifconfig reports:
# ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>
capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>
enabled=0
address: 00:0b:ab:d6:bd:15
media: Ethernet none
inet6 fe80::20b:abff:fed6:bd15%wm0 prefixlen 64 scopeid 0x11
wm1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities rx=1f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM>
capabilities tx=7f<IP4CSUM,TCP4CSUM,UDP4CSUM,TCP6CSUM,UDP6CSUM,TSO4,TSO6>
enabled=0
address: 00:0b:ab:d6:bd:16
media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause)
status: active
inet 172.27.12.3 netmask 0xffff0000 broadcast 172.27.255.255
...
View Full Message
|
|
|
Tim Sowden(deleted)
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Tim Sowden(deleted)
01/22/2018 10:34 AM
post118421
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
Hi Hugh,
Below is the output you requested
Unfortunately I can't run QNX 6 on this hardware because the version we use is 6.32 and it's too old to handle the SATA
+ Network etc. That's one of the reasons we are upgrading to QNX 7 because our old hardware is becoming obsolete and we
can't get it anymore. So the QNX 6 test you saw was the same network but different computer hardware.
One thing that is different is that in 6.32 we have a net.cfg file that contains all the I/P stuff including gateways /
DNS servers etc. That file doesn't seem to exist in QNX 7 so as I showed in my prior post I just use ifconfig to set the
IP and nothing else. But maybe it's gateway/DNS related since I don't set any of that specifically...
B000:D00:F00 @ idx 0
vid/did: 8086/191f
Intel Corporation, <device id - unknown>
class/subclass/reg: 06/00/00
Host-to-PCI Bridge Device
revid: 7
cmd/status registers: 6/2090
Capabilities: 09 (VEND) --> *
Address Space list - 0 assigned
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 2015
B000:D02:F00 @ idx 1
vid/did: 8086/1912
Intel Corporation, <device id - unknown>
class/subclass/reg: 03/00/00
PC Compatible VGA Display Controller
revid: 6
cmd/status registers: 7/10
Capabilities: 09 (VEND) --> 10 (PCIe) --> 05 (MSI) --> 01 (PMI) --> *
Address Space list - 3 assigned
[0] MEM, addr=de000000, size=1000000, align: 1000000, attr: 64bit ENABLED
[2] MEM, addr=c0000000, size=10000000, align: 10000000, attr: 64bit PREFETCH ENABLED
[4] I/O, addr=f000, size=40, align: 40, attr: 16bit ENABLED
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 2212
B000:D20:F00 @ idx 2
vid/did: 8086/a12f
Intel Corporation, <device id - unknown>
class/subclass/reg: 0c/03/30
USB Serial Bus Controller (Intel eXtensible HCI)
revid: 49
cmd/status registers: 6/290
Capabilities: 01 (PMI) --> 05 (MSI) --> *
Address Space list - 1 assigned
[0] MEM, addr=df130000, size=10000, align: 10000, attr: 64bit ENABLED
Interrupt list - 1 assigned (MSI)
Interrupt 0 on IRQ 257
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 7270
B000:D20:F02 @ idx 3
vid/did: 8086/a131
Intel Corporation, <device id - unknown>
class/subclass/reg: 11/80/00
Other DA/DSP Controller
revid: 49
cmd/status registers: 6/10
Capabilities: 01 (PMI) --> 05 (MSI) --> *
Address Space list - 1 assigned
[0] MEM, addr=df14e000, size=1000, align: 1000, attr: 64bit ENABLED
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 7270
B000:D22:F00 @ idx 4
vid/did: 8086/a13a
Intel Corporation, <device id - unknown>
class/subclass/reg: 07/80/00
Other Simple Communications Controller
revid: 49
cmd/status registers: 2/10
Capabilities: 01 (PMI) --> 05 (MSI) --> *
Address Space list - 1 assigned
[0] MEM, addr=df14d000, size=1000, align: 1000, attr: 64bit ENABLED
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 1999
B000:D23:F00 @ idx 5
vid/did: 8086/a102
Intel Corporation, <device id - unknown>
class/subclass/reg: 01/06/01
SATA Mass Storage Controller (AHCI Interface)
revid: 49
cmd/status registers: 7/2b0
Capabilities: 05 (MSI) --> 01 (PMI) --> 12 (SATA CFG) --> *
Address Space list - 6 assigned
[0] MEM, addr=df148000, size=2000, align: 2000, attr: 32bit ENABLED
[1] MEM, addr=df14c000, size=100, align: 100, attr: 32bit ENABLED
[2] I/O, addr=f090, size=8, align: 8, attr: 16bit ENABLED
[3] I/O, addr=f080, size=4, align: 4, attr: 16bit ENABLED
[4] I/O, addr=f060, size=20, align: 20, attr: 16bit ENABLED
[5] MEM, addr=df14b000, size=800, align: 800, attr: 32bit ENABLED
Interrupt list - 1 assigned (MSI)
Interrupt 0 on IRQ 256
hdrType: 0
ssvid: 8086 Intel...
View Full Message
|
|
|
Hugh Brown
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Hugh Brown
01/22/2018 2:32 PM
post118426
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
When you run the "get file" on the QNX7 machine, where is the file being written to? The fact that the "put" works fine,
tells me that the driver is working fine. Maybe this could be due to a file system slowdown, so could you try copying
the large file to another large file on the same system and see if it takes a while.
Thanks, Hugh.
On 2018-01-22, 10:13 AM, "Tim Sowden(deleted)" <community-noreply@qnx.com> wrote:
Hi Hugh,
Below is the output you requested
Unfortunately I can't run QNX 6 on this hardware because the version we use is 6.32 and it's too old to handle the
SATA + Network etc. That's one of the reasons we are upgrading to QNX 7 because our old hardware is becoming obsolete
and we can't get it anymore. So the QNX 6 test you saw was the same network but different computer hardware.
One thing that is different is that in 6.32 we have a net.cfg file that contains all the I/P stuff including
gateways / DNS servers etc. That file doesn't seem to exist in QNX 7 so as I showed in my prior post I just use ifconfig
to set the IP and nothing else. But maybe it's gateway/DNS related since I don't set any of that specifically...
B000:D00:F00 @ idx 0
vid/did: 8086/191f
Intel Corporation, <device id - unknown>
class/subclass/reg: 06/00/00
Host-to-PCI Bridge Device
revid: 7
cmd/status registers: 6/2090
Capabilities: 09 (VEND) --> *
Address Space list - 0 assigned
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 2015
B000:D02:F00 @ idx 1
vid/did: 8086/1912
Intel Corporation, <device id - unknown>
class/subclass/reg: 03/00/00
PC Compatible VGA Display Controller
revid: 6
cmd/status registers: 7/10
Capabilities: 09 (VEND) --> 10 (PCIe) --> 05 (MSI) --> 01 (PMI) --> *
Address Space list - 3 assigned
[0] MEM, addr=de000000, size=1000000, align: 1000000, attr: 64bit ENABLED
[2] MEM, addr=c0000000, size=10000000, align: 10000000, attr: 64bit PREFETCH ENABLED
[4] I/O, addr=f000, size=40, align: 40, attr: 16bit ENABLED
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 2212
B000:D20:F00 @ idx 2
vid/did: 8086/a12f
Intel Corporation, <device id - unknown>
class/subclass/reg: 0c/03/30
USB Serial Bus Controller (Intel eXtensible HCI)
revid: 49
cmd/status registers: 6/290
Capabilities: 01 (PMI) --> 05 (MSI) --> *
Address Space list - 1 assigned
[0] MEM, addr=df130000, size=10000, align: 10000, attr: 64bit ENABLED
Interrupt list - 1 assigned (MSI)
Interrupt 0 on IRQ 257
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 7270
B000:D20:F02 @ idx 3
vid/did: 8086/a131
Intel Corporation, <device id - unknown>
class/subclass/reg: 11/80/00
Other DA/DSP Controller
revid: 49
cmd/status registers: 6/10
Capabilities: 01 (PMI) --> 05 (MSI) --> *
Address Space list - 1 assigned
[0] MEM, addr=df14e000, size=1000, align: 1000, attr: 64bit ENABLED
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 7270
B000:D22:F00 @ idx 4
vid/did: 8086/a13a
Intel Corporation, <device id - unknown>
class/subclass/reg: 07/80/00
Other Simple Communications Controller
revid: 49
cmd/status registers: 2/10
Capabilities: 01 (PMI) --> 05 (MSI) --> *
Address Space list - 1 assigned
[0] MEM, addr=df14d000, size=1000, align: 1000, attr: 64bit ENABLED
Interrupt list - 0 assigned
hdrType: 0
ssvid: 8086 Intel Corporation
ssid: 1999
B000:D23:F00 @ idx 5
vid/did: 8086/a102
...
View Full Message
|
|
|
Tim Sowden(deleted)
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Tim Sowden(deleted)
01/22/2018 2:53 PM
post118427
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
Hugh,
> When you run the "get file" on the QNX7 machine, where is the file being
> written to? The fact that the "put" works fine, tells me that the driver is
> working fine. Maybe this could be due to a file system slowdown, so could you
> try copying the large file to another large file on the same system and see if
> it takes a while.
The ftp 'get' command is being run on a Windows machine (ie getting the file from the QNX machine). That's why I showed
the same transfer on a QNX 6 machine to indicate the Windows machine isn't the problem.
It's transferring data *from* the QNX 7 machine that's slow. I've tried sending from a RAM drive in addition to the hard
drive and it makes no difference so it's definitely not file I/O related. I don't think it's driver related either
since the transfer is fine in the other direction. I'm certain there must be some network configuration option that's
not right.
I can install Wireshark and do a capture but I am not sure if that's useful or not.
Tim
|
|
|
Hugh Brown
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Hugh Brown
01/22/2018 3:03 PM
post118428
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
Tim,
After running the ftp in both directions on the QNX7 machine, can you please collect the output from "netstat -s" and
send it to me?
Thanks, Hugh.
On 2018-01-22, 2:32 PM, "Tim Sowden(deleted)" <community-noreply@qnx.com> wrote:
Hugh,
> When you run the "get file" on the QNX7 machine, where is the file being
> written to? The fact that the "put" works fine, tells me that the driver is
> working fine. Maybe this could be due to a file system slowdown, so could you
> try copying the large file to another large file on the same system and see if
> it takes a while.
The ftp 'get' command is being run on a Windows machine (ie getting the file from the QNX machine). That's why I
showed the same transfer on a QNX 6 machine to indicate the Windows machine isn't the problem.
It's transferring data *from* the QNX 7 machine that's slow. I've tried sending from a RAM drive in addition to the
hard drive and it makes no difference so it's definitely not file I/O related. I don't think it's driver related either
since the transfer is fine in the other direction. I'm certain there must be some network configuration option that's
not right.
I can install Wireshark and do a capture but I am not sure if that's useful or not.
Tim
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post118427
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
Hugh Brown
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Hugh Brown
01/22/2018 3:08 PM
post118429
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
Are you running 32-bit or 64-bit under QNX7?
On 2018-01-22, 2:32 PM, "Tim Sowden(deleted)" <community-noreply@qnx.com> wrote:
Hugh,
> When you run the "get file" on the QNX7 machine, where is the file being
> written to? The fact that the "put" works fine, tells me that the driver is
> working fine. Maybe this could be due to a file system slowdown, so could you
> try copying the large file to another large file on the same system and see if
> it takes a while.
The ftp 'get' command is being run on a Windows machine (ie getting the file from the QNX machine). That's why I
showed the same transfer on a QNX 6 machine to indicate the Windows machine isn't the problem.
It's transferring data *from* the QNX 7 machine that's slow. I've tried sending from a RAM drive in addition to the
hard drive and it makes no difference so it's definitely not file I/O related. I don't think it's driver related either
since the transfer is fine in the other direction. I'm certain there must be some network configuration option that's
not right.
I can install Wireshark and do a capture but I am not sure if that's useful or not.
Tim
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post118427
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
Tim Sowden(deleted)
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
|
Tim Sowden(deleted)
01/22/2018 3:48 PM
post118430
|
Re: QNX 7 E1000 Driver Very Slow Sending Only
Hugh,
We are using the 32 bit version of QNX 7. As an FYI, our recompiled (from 6.3) S/W on QNX 7 is crashing all over the
place with suspicious memory related errors and we are allocating some large chunks (8 megs). Not sure if that means
anything.
Even the transfer of the results of the netstat commands is wildly varying.
C:\Users\admin\transfer>ftp 172.27.12.3
Connected to 172.27.12.3.
220 172.27.12.3 FTP server (QNXNTO-ftpd 20081216) ready.
502 Unknown command 'UTF8'.
User (172.27.12.3:(none)): qnxuser
331 User qnxuser accepted, provide password for qnxuser@SurfaceController.
Password:
230-No directory! Logging in with home=/
230 User qnxuser logged in.
ftp> cd /fs/ram
250 CWD command successful.
ftp> get tim
200 PORT command successful.
150 Opening ASCII mode data connection for 'tim' (12611 bytes).
226 Transfer complete.
ftp: 13020 bytes received in 1.02Seconds 12.81Kbytes/sec.
ftp> get tim1
200 PORT command successful.
150 Opening ASCII mode data connection for 'tim1' (12611 bytes).
226 Transfer complete.
ftp: 13020 bytes received in 0.00Seconds 13020000.00Kbytes/sec.
ftp> get tim2
200 PORT command successful.
150 Opening ASCII mode data connection for 'tim2' (12611 bytes).
226 Transfer complete.
ftp: 13020 bytes received in 0.00Seconds 13020000.00Kbytes/sec.
ftp> quit
221-
Data traffic for this session was 39060 bytes in 3 files.
Total traffic for this session was 39919 bytes in 3 transfers.
221 Thank you for using the FTP service on 172.27.12.3.
File tim = state of system before doing anything (in case you needed base numbers)
File tim1 = state of system after transferring file to QNX (the good direction)
File tim2 = state of system after transferring file from QNX (the bad direction)
Tim
|
|
|
Dean Denter
|
RE: QNX 7 E1000 Driver Very Slow Sending Only
|
Dean Denter
01/22/2018 5:20 PM
post118431
|
RE: QNX 7 E1000 Driver Very Slow Sending Only
Seeing a lot of TCP retransmit timeouts & ICMP errors -- have you got a really congested link or flapping port between
the 2 hosts (possible bad switchport or cable)?
Under TCP stats:
tim: 4616 retransmit timeouts
tim1: 4616 retransmit timeouts
tim2: 4702 retransmit timeouts
Under ICMP stats:
tim: 261737 calls to icmp_error
destination unreachable: 261737
tim1: 261748 calls to icmp_error
destination unreachable: 261748
tim2: 261933 calls to icmp_error
destination unreachable: 261933
|
|
|
Tim Sowden(deleted)
|
Re: RE: QNX 7 E1000 Driver Very Slow Sending Only
|
Tim Sowden(deleted)
01/22/2018 6:23 PM
post118432
|
Re: RE: QNX 7 E1000 Driver Very Slow Sending Only
> Seeing a lot of TCP retransmit timeouts & ICMP errors -- have you got a really
> congested link or flapping port between the 2 hosts (possible bad
switchport
> or cable)?
>
> Under TCP stats:
> tim: 4616 retransmit timeouts
> tim1: 4616 retransmit timeouts
> tim2: 4702 retransmit timeouts
>
> Under ICMP stats:
> tim: 261737 calls to icmp_error
> destination unreachable: 261737
> tim1: 261748 calls to icmp_error
> destination unreachable: 261748
> tim2: 261933 calls to icmp_error
> destination unreachable: 261933
>
>
The computers are all located in a lab with no outside access (closed network) so there is very little traffic.
I swapped Ethernet cables on the chance it might have been a bad cable I used but that made no difference. I was *this*
close to writing back when I decided to switch ports on the Netgear router. I hadn't done that prior because I had
plugged into a port that was being used by another computer in our lab so I *knew* it was good.
Of course the instant I plugged into another port everything started working in both directions. So the port must have
been degraded after all and just no one has noticed because they haven't transferred any large amount of data in the bad
direction on the prior machine that was plugged in there!
One final question though. I swore prior versions of QNX showed these types of hardware issues in Nicinfo which was the
first place I went when I was having problems. The fact there were no errors reported there made me think it was a
configuration issue vs a hardware one.
Thanks for all your help,
Tim
|
|
|
|