I have found a Sandy Bridge board, so will let you know when I have the
network driver working.

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
 

Matthias,

You will have to speak to Kontron about re-programming the EEPROM on your
board with a correct MAC address. I have been in contact with Intel and the
MAC address that you have on your machine is the default address if no MAC
address is programmed.

I should have an experimental driver ready for you to test either later
today or on Monday.

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
 

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

Steffen,

I have attached 2 output files from your new Client program, so I don¹t know
why you are seeing such large delays. As you can see from the 2 output
files, my times are in the 100-200us range. I am running the test using a
gigabit switch. If I run the test through a 100Mb switch I see the delay on
the first packet, but I¹m not sure what is causing this, as the link is up
at this time. I can only imagine that it must be something to do with either
the chip or the PHY, as the driver has no control over this.

Hugh.


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

> 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
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87264
> 

-- 
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 use a 100Mbit switch. So I think it's a normal transmission time because the best case without telegram overhead would
 be 610us. Only the 1000us is a little bit too long.

In my application the driver runs quite good, now. When do you think can I get a released version of it?

Best regards,

Steffen

You will have to contact your local QNX office and request an official
version of the driver. Glad to hear that it is working for you.

Hugh.


On 11-08-02 4:58 AM, "Steffen Brühl" <community-noreply@qnx.com> wrote:

> I use a 100Mbit switch. So I think it's a normal transmission time because the
> best case without telegram overhead would be 610us. Only the 1000us is a
> little bit too long.
> 
> In my application the driver runs quite good, now. When do you think can I get
> a released version of it?
> 
> Best regards,
> 
> Steffen
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post87751
> 
> 

-- 
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
 

Hi Hugh,
I got a new driver from the BSP directory:
http://community.qnx.com/sf/frs/do/viewRelease/projects.bsp/frs.x86_bios.bsp_nto650_x86_bios_trunk

Unfortunately with this driver, which probably will be released, I have timing problems again.

In other words, the driver you posted here works and the new driver from the BSP doesn't work.

With best regards,

Steffen

Maybe you are interested in the driver I build by myself.

So what did you change in the driver?

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-01-19 5:05 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Maybe you are interested in the driver I build by myself.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91005

Hi Hugh,

I only compiled the recent BSP and was wondering why the driver didn't work as the older experimental driver you posted 
here.

I didn't change anything!

Best regards,

Steffen

OK thanks. I'll investigate further.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-09 7:47 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I only compiled the recent BSP and was wondering why the driver didn't
>work as the older experimental driver you posted here.
>
>I didn't change anything!
>
>Best regards,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91432
>

Hi Steffen,

I have been testing the attached driver for several hours now without a
problem, so please will you give it a try and let me know the outcome. I
will leave it running overnight.

Many thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-09 7:47 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I only compiled the recent BSP and was wondering why the driver didn't
>work as the older experimental driver you posted here.
>
>I didn't change anything!
>
>Best regards,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91432
>

Hi Hugh,

thank you very much for the driver. It seems to work. I haven't seen any timeouts for a few hours, now.

What do you think, when it will be released?

With best regards,

Steffen

Hi Steffen,

Good news! I have had it running all night without any timeouts. I'll have
to find out when the x86 BSP will be rebuilt and will let you know. Thanks
for your patience!

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-10 7:29 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>thank you very much for the driver. It seems to work. I haven't seen any
>timeouts for a few hours, now.
>
>What do you think, when it will be released?
>
>With best regards,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91469
>

Hi Steffen,

There are some fixes to be made to the x86 BSP, so I cannot give you an
exact date as to when it will be released. If I remember, I'll let you
know when it is ready.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-10 7:29 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>thank you very much for the driver. It seems to work. I haven't seen any
>timeouts for a few hours, now.
>
>What do you think, when it will be released?
>
>With best regards,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91469
>

Hi Hugh,

now I have problems starting the driver.
I have two ethernet devices:
Intel 82574L: Vendor ID = 8086h Device ID = 10d3h
Intel 82579LM: Vendor ID = 8086h Device ID = 1502h

I start the two ethernet devices as follows:

enum-devices -c net.conf -e pci
if_up -p en0
if [ "$?" -ne 0 ]
then
  echo "Error: No ethernet device 1!"
else
  ifconfig en0 172.16.200.1 netmask 255.255.0.0
  if_up -l en0
  if [ "$?" -ne 0 ]
  then
    echo "Error: No ethernet link 1!"
  fi
fi

SOCK=/dev/socket2 if_up -p en0
if [ "$?" -ne 0 ]
then
  echo "Error: No ethernet device 2!"
else
  SOCK=/dev/socket2 ifconfig en0 172.16.200.2 netmask 255.255.0.0
  SOCK=/dev/socket2 if_up -l en0
  if [ "$?" -ne 0 ]
  then
    echo "Error: No ethernet link 2!"
  fi
fi

For the first device the sequence runs without any delay.
For the second device "SOCK=/dev/socket2 if_up -p en0" needs between 5 and 10s and "SOCK=/dev/socket2 ifconfig en0 172.
16.200.2 netmask 255.255.0.0" needs between 5 and 10s.

The old driver doesn't have this problem.

I attached the sloginfo. 

Is it possible to get a driver talking not so much, because not all information is included in sloginfo, now.


Best regards,

Steffen

Hi Steffen,

I you start the driver without verbose, you won't get all these messages
in sloginfo.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 8:48 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>now I have problems starting the driver.
>I have two ethernet devices:
>Intel 82574L: Vendor ID = 8086h Device ID = 10d3h
>Intel 82579LM: Vendor ID = 8086h Device ID = 1502h
>
>I start the two ethernet devices as follows:
>
>enum-devices -c net.conf -e pci
>if_up -p en0
>if [ "$?" -ne 0 ]
>then
>  echo "Error: No ethernet device 1!"
>else
>  ifconfig en0 172.16.200.1 netmask 255.255.0.0
>  if_up -l en0
>  if [ "$?" -ne 0 ]
>  then
>    echo "Error: No ethernet link 1!"
>  fi
>fi
>
>SOCK=/dev/socket2 if_up -p en0
>if [ "$?" -ne 0 ]
>then
>  echo "Error: No ethernet device 2!"
>else
>  SOCK=/dev/socket2 ifconfig en0 172.16.200.2 netmask 255.255.0.0
>  SOCK=/dev/socket2 if_up -l en0
>  if [ "$?" -ne 0 ]
>  then
>    echo "Error: No ethernet link 2!"
>  fi
>fi
>
>For the first device the sequence runs without any delay.
>For the second device "SOCK=/dev/socket2 if_up -p en0" needs between 5
>and 10s and "SOCK=/dev/socket2 ifconfig en0 172.16.200.2 netmask
>255.255.0.0" needs between 5 and 10s.
>
>The old driver doesn't have this problem.
>
>I attached the sloginfo.
>
>Is it possible to get a driver talking not so much, because not all
>information is included in sloginfo, now.
>
>
>Best regards,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91590

Hi Hugh,

I know that, but I use the entries for diagnostic information.

Now, I got a more serious problem.
"SOCK=/dev/socket2 ifconfig en0 172.16.200.2 netmask 255.255.0.0 " completely hangs. The OS doesn't interact anymore!!

Best regard,

Steffen

You can try editing the /etc/system/enum/include/net file and adding
"stacksize=8192" after the -ptcpip and see if that helps.
I also have 2 e1000 interfaces on my machine and the standard enumerator
starts the driver for both interfaces just fine.
I will see about the verbosity level in the driver.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 9:21 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I know that, but I use the entries for diagnostic information.
>
>Now, I got a more serious problem.
>"SOCK=/dev/socket2 ifconfig en0 172.16.200.2 netmask 255.255.0.0 "
>completely hangs. The OS doesn't interact anymore!!
>
>Best regard,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91595
>

Hi Hugh,

I don't use the standard enumeration file. I start the drivers as follows:
device(pci,ven=8086,dev=10d3,index=0)
   start("io-pkt-v6-hc -de1000 verbose=1,pci=0x0,priority=9,vid=0x8086,did=0x10d3 -ptcpip rx_pulse_prio=9")

device(pci,ven=8086,dev=1502,index=0)
   start("io-pkt-v4 -de1000 verbose=3,pci=0x0,priority=57,vid=0x8086,did=0x1502 -ptcpip rx_pulse_prio=57,prefix=/dev/
socket2")

If I change "prefix=/dev/socket2" to the other device, the other device delayes.

What does that men in the sloginfo? It needs a lot of time:
Feb 15 14:21:23    6    10     0 SW has already locked the resource.
Feb 15 14:21:23    6    10     0 SW has already locked the resource.
Feb 15 14:21:23    6    10     0 SW has already locked the resource.
Feb 15 14:21:24    6    10     0 SW has already locked the resource.
Feb 15 14:21:24    6    10     0 SW has already locked the resource.
Feb 15 14:21:24    6    10     0 SW has already locked the resource.
Feb 15 14:21:25    6    10     0 SW has already locked the resource.
Feb 15 14:21:25    6    10     0 SW has already locked the resource.

Best regards,

Steffen 

Hi Steffen,

Do you get the "SW has already locked the resource." message for both
devices or only one? If it is only for one, which device is it?

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 10:22 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I don't use the standard enumeration file. I start the drivers as follows:
>device(pci,ven=8086,dev=10d3,index=0)
>   start("io-pkt-v6-hc -de1000
>verbose=1,pci=0x0,priority=9,vid=0x8086,did=0x10d3 -ptcpip
>rx_pulse_prio=9")
>
>device(pci,ven=8086,dev=1502,index=0)
>   start("io-pkt-v4 -de1000
>verbose=3,pci=0x0,priority=57,vid=0x8086,did=0x1502 -ptcpip
>rx_pulse_prio=57,prefix=/dev/socket2")
>
>If I change "prefix=/dev/socket2" to the other device, the other device
>delayes.
>
>What does that men in the sloginfo? It needs a lot of time:
>Feb 15 14:21:23    6    10     0 SW has already locked the resource.
>Feb 15 14:21:23    6    10     0 SW has already locked the resource.
>Feb 15 14:21:23    6    10     0 SW has already locked the resource.
>Feb 15 14:21:24    6    10     0 SW has already locked the resource.
>Feb 15 14:21:24    6    10     0 SW has already locked the resource.
>Feb 15 14:21:24    6    10     0 SW has already locked the resource.
>Feb 15 14:21:25    6    10     0 SW has already locked the resource.
>Feb 15 14:21:25    6    10     0 SW has already locked the resource.
>
>Best regards,
>
>Steffen 
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91602
>

Hi Hugh,

I don't know which device it is. I got it from the sloginfo output I attached a few replys ago.

Regards, Steffen

Please give this driver a try and see if it rectifies the problem.

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 10:37 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I don't know which device it is. I got it from the sloginfo output I
>attached a few replys ago.
>
>Regards, Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91605
>

The delay is still there.

Regards, Steffen

OK, I see what's happening. I'll have to take a look at it tomorrow.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 10:58 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>The delay is still there.
>
>Regards, Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91609
>

Hi Steffen,

Here's a new driver for you to try.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 10:58 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>The delay is still there.
>
>Regards, Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91609
>

Hi Hugh,

the driver works, now. I don't have any delay.

I'll run it over night to see if I'll get any timeouts.

Thank you very much.

Best regards,

Steffen

I have setup a machine with the same 2 chipsets that you have and have
changed my rc.local as follows:

slay -f io-pkt-v4-hc netmanager dhcp.client
sleep 1
io-pkt-v6-hc -de1000 verbose=1,priority=9,vid=0x8086,did=0x10d3 -ptcpip
rx_pulse_prio=9
sleep 2
io-pkt-v4 -de1000 verbose=3,priority=57,vid=0x8086,did=0x1502 -ptcpip
rx_pulse_prio=57,prefix=/dev/socket2
dhcp.client -iwm0
sleep 1
SOCK=/dev/socket2 ifconfig wm0 172.16.0.50
inetd

My machine comes up with no problems. Can you please try the same and see
if you still have the problem?

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 10:22 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I don't use the standard enumeration file. I start the drivers as follows:
>device(pci,ven=8086,dev=10d3,index=0)
>   start("io-pkt-v6-hc -de1000
>verbose=1,pci=0x0,priority=9,vid=0x8086,did=0x10d3 -ptcpip
>rx_pulse_prio=9")
>
>device(pci,ven=8086,dev=1502,index=0)
>   start("io-pkt-v4 -de1000
>verbose=3,pci=0x0,priority=57,vid=0x8086,did=0x1502 -ptcpip
>rx_pulse_prio=57,prefix=/dev/socket2")
>
>If I change "prefix=/dev/socket2" to the other device, the other device
>delayes.
>
>What does that men in the sloginfo? It needs a lot of time:
>Feb 15 14:21:23    6    10     0 SW has already locked the resource.
>Feb 15 14:21:23    6    10     0 SW has already locked the resource.
>Feb 15 14:21:23    6    10     0 SW has already locked the resource.
>Feb 15 14:21:24    6    10     0 SW has already locked the resource.
>Feb 15 14:21:24    6    10     0 SW has already locked the resource.
>Feb 15 14:21:24    6    10     0 SW has already locked the resource.
>Feb 15 14:21:25    6    10     0 SW has already locked the resource.
>Feb 15 14:21:25    6    10     0 SW has already locked the resource.
>
>Best regards,
>
>Steffen 
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91602
>

Here is a driver with less verbosity.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-15 9:21 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>I know that, but I use the entries for diagnostic information.
>
>Now, I got a more serious problem.
>"SOCK=/dev/socket2 ifconfig en0 172.16.200.2 netmask 255.255.0.0 "
>completely hangs. The OS doesn't interact anymore!!
>
>Best regard,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91595
>

Hi Steffen,

I'll have to take a look at this and get back to you.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 1Y5.
Telephone: 613-591-0931







On 12-01-19 5:03 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>I got a new driver from the BSP directory:
>http://community.qnx.com/sf/frs/do/viewRelease/projects.bsp/frs.x86_bios.b
>sp_nto650_x86_bios_trunk
>
>Unfortunately with this driver, which probably will be released, I have
>timing problems again.
>
>In other words, the driver you posted here works and the new driver from
>the BSP doesn't work.
>
>With best regards,
>
>Steffen
>
>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91004
>

Hi Steffen,

Please try the attached driver and let me know whether it solves the
problem or not.

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-01-19 5:03 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>I got a new driver from the BSP directory:
>http://community.qnx.com/sf/frs/do/viewRelease/projects.bsp/frs.x86_bios.b
>sp_nto650_x86_bios_trunk
>
>Unfortunately with this driver, which probably will be released, I have
>timing problems again.
>
>In other words, the driver you posted here works and the new driver from
>the BSP doesn't work.
>
>With best regards,
>
>Steffen
>
>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91004
>

Hi Hugh,

thanks for the driver. It doesn't solve the problem. The old driver works much more better in my case.

Best regards,

Steffen

Hi Steffen,

That's strange, as I tested the driver with your test programs and the
only delay that I got was on the first buffer. What problem are you seeing?

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931







On 12-02-01 2:47 AM, "Steffen B." <community-noreply@qnx.com> wrote:

>Hi Hugh,
>
>thanks for the driver. It doesn't solve the problem. The old driver works
>much more better in my case.
>
>Best regards,
>
>Steffen
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post91274
>

Hi Hugh,

you're right, with my test program I can't reproduce it, too.

But with my application I get timeouts after a view minutes. It's a bit different to my test program. There I have three
 devices communicating together and more connections through the same port.

There must be a difference to the old driver you posted here, because this driver works in my application.

With best regards,

Steffen

Hi Hugh,

I extended my test applications. Now you can set a timeout to the client:
EthClient ip-address [timeout in us]
If you don't set a timeout every transmission time is printed out.
If you set a timeout the transmission time is only printed out if the transmission needs longer than the given timeout.

Normally my data transfer needs about 1150us. I run the test application over night as follows:
EthClient 172.16.205.4 2000

-> With the current driver I could see transmission times up to 50ms.

Please use the attached server.

Bests regards,

Steffen

Here comes the client.