I tested the latest driver you posted here and it works.

But in general I have timing problems with the e1000 driver.

I solved the problems using APIC (see also http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/
discussion.drivers.topc20387)

Regards,

Steffen

Here is the experimental driver for you to test. You can override the MAC
address by specifying ³mac=001122334455² on the command line.

Please let me know how it goes.

Thanks, Hugh.


On 11-05-19 9:09 AM, "Matthias Ecker" <community-noreply@qnx.com> wrote:

> Dear Hugh,
> 
> you'll find the requested information attached to this reply. Please let me
> know if you need any further information.
> 
> Regards,
> Matthias
> 
>   196  slay slogger
>   197  use slogger
>   198  slogger -s 1024
>   199  io-pkt-v4-hc -i2 -ptcpip prefix=/alt -de1000_5
> verbose=10,pci=0,did=0x1502
>   200  SOCK=/alt ifconfig wm0 up
>   201  SOCK=/alt ifconfig wm0 192.168.70.20
>   202  SOCK=/alt ifconfig
>   203  sloginfo > sloginfo.out4
>   204  pci -vv > pcivv.txt
>   205  tar -cvf info.tar sloginfo.out4 pcivv.txt
>   206  history
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post85931
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Dear Hugh,

this one is working! media detection worked and I could ping and telnet other hosts in the net. Great work!

It is a adlink nu-pro-e340 test slot cpu (not the final version). I'm in contact with our sales director and told him 
the problems with the mac address. He forwarded the information the board developer.

Do you need further tests? sloginfo output? 

May I use this driver for testing purposes, or is it too "experimental"? 

Thanks,
Matthias

Hi Matthias,

Good news! You can use this driver for testing purposes. I have run some
basic tests with the driver, but I think that it should be pretty stable.

I don¹t need any further output.

Thanks, Hugh.


On 11-05-30 3:31 AM, "Matthias Ecker" <community-noreply@qnx.com> wrote:

> Dear Hugh,
> 
> this one is working! media detection worked and I could ping and telnet other
> hosts in the net. Great work!
> 
> It is a adlink nu-pro-e340 test slot cpu (not the final version). I'm in
> contact with our sales director and told him the problems with the mac
> address. He forwarded the information the board developer.
> 
> Do you need further tests? sloginfo output?
> 
> May I use this driver for testing purposes, or is it too "experimental"?
> 
> Thanks,
> Matthias
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post86239
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Matthias,

Here is the updated enumeration file, so that the driver will start
automatically at boot time. You can copy this file to
/etc/system/enum/devices.

Hugh.



On 11-05-30 3:31 AM, "Matthias Ecker" <community-noreply@qnx.com> wrote:

> Dear Hugh,
> 
> this one is working! media detection worked and I could ping and telnet other
> hosts in the net. Great work!
> 
> It is a adlink nu-pro-e340 test slot cpu (not the final version). I'm in
> contact with our sales director and told him the problems with the mac
> address. He forwarded the information the board developer.
> 
> Do you need further tests? sloginfo output?
> 
> May I use this driver for testing purposes, or is it too "experimental"?
> 
> Thanks,
> Matthias
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post86239
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Unfortunately I still have timing problems with the driver although I use APIC.

The original driver which was delivered with QNX 6.5.0 runs with Intel 82574L with real telegram traffic very well 
(without APIC).

The driver posted here disrupts or delays traffic.

Regards,

Steffen

Please can you explain what you mean by ³disrupts or delays traffic²? How
are you measuring this? What hardware is this running on?

Thanks, Hugh.


On 11-06-30 9:47 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> Unfortunately I still have timing problems with the driver although I use
> APIC.
> 
> The original driver which was delivered with QNX 6.5.0 runs with Intel 82574L
> with real telegram traffic very well (without APIC).
> 
> The driver posted here disrupts or delays traffic.
> 
> Regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post86982
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

I use the following hardware:
Fujitsu D3076 mainboard with Q67 chipset, i7-2600K Sandy Bridge processor, Ethernet Intel 82574L and 82579LM.

I have a connection to another PC and I send and receive every 100ms about 2MB Data with 40ms timeout.

Normally this data transfer needs less than 1ms but sometimes the transfer stops and I run into my 40ms timeout.

As I mentioned before, with the released driver I do not have any problems.

Best regards,

Steffen

Please will you run the attached ttcp program and let me know what type of
throughput you get. I have tested this on our Sandy Bridge platform (Intel
reference) and consistently get 70MB/s throughput. I am running the test via
a gigabit switch to another x86 PC. Please run the program as follows:

On server:

ttcp ­s ­r

On client:

ttcp ­s ­t ­n100000 ip.address

Thanks, Hugh.


On 11-06-30 10:45 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I use the following hardware:
> Fujitsu D3076 mainboard with Q67 chipset, i7-2600K Sandy Bridge processor,
> Ethernet Intel 82574L and 82579LM.
> 
> I have a connection to another PC and I send and receive every 100ms about 2MB
> Data with 40ms timeout.
> 
> Normally this data transfer needs less than 1ms but sometimes the transfer
> stops and I run into my 40ms timeout.
> 
> As I mentioned before, with the released driver I do not have any problems.
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post86988
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

I should add that I am also running this in APIC mode and have also tested
with another e1000 adapter plugged into a PCIe socket, with the same
results.


On 11-06-30 10:45 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I use the following hardware:
> Fujitsu D3076 mainboard with Q67 chipset, i7-2600K Sandy Bridge processor,
> Ethernet Intel 82574L and 82579LM.
> 
> I have a connection to another PC and I send and receive every 100ms about 2MB
> Data with 40ms timeout.
> 
> Normally this data transfer needs less than 1ms but sometimes the transfer
> stops and I run into my 40ms timeout.
> 
> As I mentioned before, with the released driver I do not have any problems.
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post86988
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

I started the program as follows, but nothing happens:

Server:
# SOCK=/dev/socket2 ttcp -­s -­r
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket

Client:
# SOCK=/dev/socket2 ttcp ­-s -­t -­n100000 172.16.205.4
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket

What is wrong?

I tested the new driver on an older system (Core 2 Quad with G41 chipset, ICH7 and PCI express eth), too. I had the same
 problems. But the released driver works very well.

Best regards,

Steffen

There should only be one ‘-’ for each of the options. I see that you have 2.


On 11-07-01 2:50 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I started the program as follows, but nothing happens:
> 
> Server:
> # SOCK=/dev/socket2 ttcp -­s -­r
> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
> ttcp-r: socket
> 
> Client:
> # SOCK=/dev/socket2 ttcp ­-s -­t -­n100000 172.16.205.4
> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
> ttcp-r: socket
> 
> What is wrong?
> 
> I tested the new driver on an older system (Core 2 Quad with G41 chipset, ICH7
> and PCI express eth), too. I had the same problems. But the released driver
> works very well.
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87011
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

I used only one "-". If you look directly in the forum, there is only displayed one "-" .

Best regards,

Steffen

Can you try with just one interface running? Start ‘io-pkt-v4 –de1000
did=0x1502’ then ifconfig the interface and run ttcp.

If you started io-pkt with the prefix command (prefix=/alt), then you should
start ttcp as “SOCK=/alt ttcp ...”.


On 11-07-01 2:50 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I started the program as follows, but nothing happens:
> 
> Server:
> # SOCK=/dev/socket2 ttcp -­s -­r
> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
> ttcp-r: socket
> 
> Client:
> # SOCK=/dev/socket2 ttcp ­-s -­t -­n100000 172.16.205.4
> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
> ttcp-r: socket
> 
> What is wrong?
> 
> I tested the new driver on an older system (Core 2 Quad with G41 chipset, ICH7
> and PCI express eth), too. I had the same problems. But the released driver
> works very well.
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87011
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Sorry, but I still don't get any output. I started the program as follows:

Server:
io-pkt-v4 -drtl8169 verbose=4,pci=0x0,vid=0x10ec,did=0x8168 -ptcpip
waitfor /dev/socket
ifconfig en0 172.16.205.4 netmask 255.255.0.0
ttcp ­s ­r

Client:
io-pkt-v4 -de1000 verbose=1,pci=0x0,vid=0x8086,did=0x1502 -ptcpip
waitfor /dev/socket
ifconfig en0 172.16.205.3 netmask 255.255.0.0
ttcp -s -t -n100000 172.16.205.4

Best regards,

Steffen

Can you ping from one node to another? Also can you do a ‘cksum ttcp’. The
output from mine is below.
1944084984 26431 ttcp

Thanks, Hugh.



On 11-07-04 11:21 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> Sorry, but I still don't get any output. I started the program as follows:
> 
> Server:
> io-pkt-v4 -drtl8169 verbose=4,pci=0x0,vid=0x10ec,did=0x8168 -ptcpip
> waitfor /dev/socket
> ifconfig en0 172.16.205.4 netmask 255.255.0.0
> ttcp ­s ­r
> 
> Client:
> io-pkt-v4 -de1000 verbose=1,pci=0x0,vid=0x8086,did=0x1502 -ptcpip
> waitfor /dev/socket
> ifconfig en0 172.16.205.3 netmask 255.255.0.0
> ttcp -s -t -n100000 172.16.205.4
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87042
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

I can ping and the checksum is the same.

Regards,

Steffen

Steffen,

Are you starting the programs in a script? Looking at your previous post, I
see that you have a waitfor /dev/socket, so that is why I am assuming you
are running a script. You should have a ³sleep 3² between the ifconfig and
starting the ttcp, as the link auto-negotiation takes about 3 seconds.

Hugh.


On 11-07-05 2:31 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I can ping and the checksum is the same.
> 
> Regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87050
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Further to my last e-mail, do you have a sample program that you are using
to detect the delay? If so, could I have a copy to do some testing here?

Thanks, Hugh.


On 11-07-05 2:31 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I can ping and the checksum is the same.
> 
> Regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87050
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Sorry, but the delay didn't help, too. But I wrote my own application and I have about 10MB/s with a 100Mb/s-switch.

Then I wrote a test application (see atachment). Every 100ms 8002 bytes are transfered to a server and back. This should
 normally need about 1600us. That means for one way 800us and I detected about 850us. If the time is bigger than 1000us 
I print out the time value.

The first transfer in my systems always needs about 200ms. I don't know why. And then you shouldn't have any output if 
the transfer works properly.

The server you should start without any parameters. The client needs the ip address of the server system: EthClient ip.
address

Best regards,

Steffen

The client comes here.

Steffen,

Thank you very much for the test programs ­ they enabled me to find the
problem and fix it. I have attached an updated driver for you to test, so
please let me know if everything is working OK now.

Thanks, Hugh.


On 11-07-06 4:28 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> The client comes here.
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87115
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Limited.   (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

Thank you very much for the driver. In general the driver works now. I don't have these long delays any more.

But I still have problems:
- With 82579LM device the transmission needs more than 1000us (this can be reproduced with my test programs). Normally I
 tested with 82574L device and transmission needs only about 850us.

- With 82574L device my system runs about 2 hours. Then a timeout occurs to a third network device. With my old Core 2 
Quad system and PCI Express ethernet adapter with 82574L controller and the new driver the system runs very well.

Best regards,

Steffen

The transmit routine is the same for all the chipsets, so I don¹t see how I
can change the time required for transmission. When I tested the new driver
with your test program, I didn¹t see any timeout messages at all.

Hugh.


On 11-07-11 8:55 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> Thank you very much for the driver. In general the driver works now. I don't
> have these long delays any more.
> 
> But I still have problems:
> - With 82579LM device the transmission needs more than 1000us (this can be
> reproduced with my test programs). Normally I tested with 82574L device and
> transmission needs only about 850us.
> 
> - With 82574L device my system runs about 2 hours. Then a timeout occurs to a
> third network device. With my old Core 2 Quad system and PCI Express ethernet
> adapter with 82574L controller and the new driver the system runs very well.
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87239
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Limited.   (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8
 

I changed my EthClient (see attachment) to print out every transmission time. Here are the results:

82574L:
0: 196086 us for 8002 bytes
1: 895 us for 8002 bytes
2: 874 us for 8002 bytes
3: 914 us for 8002 bytes
4: 893 us for 8002 bytes
5: 934 us for 8002 bytes
6: 915 us for 8002 bytes
7: 893 us for 8002 bytes
8: 872 us for 8002 bytes
9: 913 us for 8002 bytes
10: 892 us for 8002 bytes
11: 871 us for 8002 bytes
12: 913 us for 8002 bytes
13: 892 us for 8002 bytes
14: 888 us for 8002 bytes
15: 911 us for 8002 bytes
16: 891 us for 8002 bytes
17: 869 us for 8002 bytes
18: 909 us for 8002 bytes
19: 887 us for 8002 bytes

82579LM:
0: 206610 us for 8002 bytes
1: 1015 us for 8002 bytes
2: 1014 us for 8002 bytes
3: 1014 us for 8002 bytes
4: 1014 us for 8002 bytes
5: 1014 us for 8002 bytes
6: 1014 us for 8002 bytes
7: 1013 us for 8002 bytes
8: 1012 us for 8002 bytes
9: 1013 us for 8002 bytes
10: 1012 us for 8002 bytes
11: 1014 us for 8002 bytes
12: 1014 us for 8002 bytes
13: 1013 us for 8002 bytes
14: 1014 us for 8002 bytes
15: 1013 us for 8002 bytes
16: 1014 us for 8002 bytes
17: 1013 us for 8002 bytes
18: 1013 us for 8002 bytes
19: 1012 us for 8002 bytes

Maybe the transmission time is different bacause one is a controller and the other a PHY?

I also don't understand, why the first transmission needs so much time.

Best regards,

Steffen