|
|
Card does not support Jumbo Frames
|
|
02/09/2009 1:07 PM
post21789
|
Card does not support Jumbo Frames
Hey Guys,
I just looked at the nic settings in Windows and it's my mistake to ask about the jumbo packets because it seems that
the hardware does not support it. I checked all of the settings on the driver but came up empty.
I have been testing the camera without jumbo frames and it still works. The jumbo packets were suggested to reduce the
number of interrupts caused by the network card, but the CPU load with a core 2 duo was under 25% on both cores so I'm
not going to worry about it.
Thanks,
Kevin
|
|
|
|
|
|
|
RE: Card does not support Jumbo Frames
|
|
02/09/2009 1:09 PM
post21790
|
RE: Card does not support Jumbo Frames
Kevin out of curiosity what camera are you using? GigE protocol?
> -----Original Message-----
> From: KEvin Raymond [mailto:community-noreply@qnx.com]
> Sent: February-09-09 1:08 PM
> To: drivers-networking
> Subject: Card does not support Jumbo Frames
>
> Hey Guys,
>
> I just looked at the nic settings in Windows and it's my mistake to ask
> about the jumbo packets because it seems that the hardware does not
> support it. I checked all of the settings on the driver but came up
> empty.
>
> I have been testing the camera without jumbo frames and it still works.
> The jumbo packets were suggested to reduce the number of interrupts
> caused by the network card, but the CPU load with a core 2 duo was
> under 25% on both cores so I'm not going to worry about it.
>
> Thanks,
> Kevin
>
> _______________________________________________
> Networking Drivers
> http://community.qnx.com/sf/go/post21789
>
|
|
|
|
|
|
02/10/2009 9:42 AM
post21877
|
Hey,
I'm using a GigE Prosilica camera and trying to get 15 frames per second out of it.
We tested it yesterday at lunch time and found that we could get 15 frames per second for a full hour with the new
driver.
It seems to be very stable and most importantly fast once everything has booted up.
Kevin
|
|
|
|
|
|
|
RE: Card does not support Jumbo Frames
|
|
02/09/2009 2:27 PM
post21800
|
RE: Card does not support Jumbo Frames
You might also want to try enabling hardware checksumming and see if
that helps to reduce your CPU usage somewhat.
ifconfig bge0 ip4csum udp4csum tcp4csum
Robert.
-----Original Message-----
From: KEvin Raymond [mailto:community-noreply@qnx.com]
Sent: Monday, February 09, 2009 1:08 PM
To: drivers-networking
Subject: Card does not support Jumbo Frames
Hey Guys,
I just looked at the nic settings in Windows and it's my mistake to ask
about the jumbo packets because it seems that the hardware does not
support it. I checked all of the settings on the driver but came up
empty.
I have been testing the camera without jumbo frames and it still works.
The jumbo packets were suggested to reduce the number of interrupts
caused by the network card, but the CPU load with a core 2 duo was under
25% on both cores so I'm not going to worry about it.
Thanks,
Kevin
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post21789
|
|
|
|
|
|
|
RE: Card does not support Jumbo Frames
|
|
02/10/2009 9:53 AM
post21880
|
RE: Card does not support Jumbo Frames
> the hardware does not support (jumbo packets)
This is actually not very surprising - remember
that there is absolutely NO official specification
for jumbo packets. No one even agrees what the
MTU is, for a jumbo packet!
And to support jumbo packets, you also need to buy
the "right" gige switches.
If you do switch to another adapter which supports
jumbo packets, you can notice a measureable drop in cpu
consumption during large data transfers, especially
with judicious use of the mclbytes and pagesize
option to io-pkt, to avoid internally fragmenting
the jumbo packets, reduce descriptor use, etc.
--
aboyd
|
|
|
|
|
|
02/09/2009 12:11 PM
post21780
|
Hi Kevin:
Quick update on the jumbo packets. From some web postings, it
looks like the chipset doesn't actually support jumbo packets. Can't
seem to find anything specifically on the Broadcom website though.
http://www.smallnetbuilder.com/content/view/30549/75/1/1/
(See the comment:
"Updated 8/18/2008
QNAP responded that the Broadcom BCM5787 does not support jumbo frames.
But they chose it because it had the best throughput of the chipsets
they evaluated. ")
Robert.
-----Original Message-----
From: Robert Craig
Sent: Monday, February 09, 2009 11:46 AM
To: 'post21761@community.qnx.com'
Subject: RE: Success (Almost)
Hi Kevin:
I've looked through the source and there's bad news on the
Jumnbo packet front. It looks like Jumbo packet usage is restricted to
only a certain variety of BCM chip IDs due to some sort of "chip set
quirks". I'll take a closer look into the NetBSD source to see why this
would be the case, but the behaviour that you're seeing is expected...
In terms of nicinfo, this is also expected. We hooked in some plumbing
to nicinfo to provide basic feedback for NetBSD style drivers (packet
counts essentially), but the output is by no means complete. "ifconfig"
(or ifconfig -v) for these drivers generally provides equivalent (and in
some cases better) output.
I'm not sure about the initial timeouts (I'll take a look). The second
timeout (with netmanager) I THINK makes sense since it will try and
bring up the interface and wait for DHCP to fail before it continues. I
belive that you can get around this by marking the interface as disabled
in the network configuration manager.
R.
-----Original Message-----
From: KEvin Raymond [mailto:community-noreply@qnx.com]
Sent: Monday, February 09, 2009 10:27 AM
To: drivers-networking
Subject: Success (Almost)
Hello Robert,
Thanks for all your suport so far. I was testing the driver this morning
and can confirm that it did work, however I saw a coule of things which
you will probably want to know about.
1st. The MTU canot be changed to a value larger than 1500. I was hoping
to use ~8000 for the camera I will need to interact with. No the end of
the world, but it would be nice to get working.
2nd. There is still a large hang on bootup or starting the driver, but
it only occurs if there is noactive network cable connected to the
broadcom nic. We saw this because only one of the dual onboard nics was
connected. Again this is not the end of the world, we can diable in the
bios the nic that we son't be using. Please refer to the attached
ssloginfo dumps to see exactly why there is a delay. I added in some
comments to help identify exactly where they are.
3rd. Some of the info displayed by nicinfo was incorrect. the MTU seems
to be correct with 1500, bu the MRU should be greater than 0.
Please take a look
bge0:
Broadcom Gigabit Ethernet Controller
Physical Node ID ........................... 00187D 03F4D4
Current Physical Node ID ................... 00187D 03F4D4
Current Operation Rate ..................... 1000.00 Mb/s full-duplex
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 0
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
Packets Transmitted OK ..................... 878
Bytes Transmitted OK ....................... 124790
Multicast Packets Transmitted OK ........... 0
Packets Received OK ........................ 4475
Bytes Received OK .......................... 491499
Multicast Packets Received OK .............. 3847
bge1:
Broadcom Gigabit Ethernet Controller
Physical Node ID ........................... 00187D 03F4D5
Current Physical Node ID ................... 00187D 03F4D5
Current Operation Rate...
View Full Message
|
|
|
|
|
|
02/09/2009 12:12 PM
post21781
|
I`m not 100% sure but I think I`ve played with this NIC on a windows machine and it didn`t seems to support jumbo
packets.
> -----Original Message-----
> From: Robert Craig [mailto:community-noreply@qnx.com]
> Sent: February-09-09 12:12 PM
> To: drivers-networking
> Subject: RE: Success (Almost)
>
>
> Hi Kevin:
>
> Quick update on the jumbo packets. From some web postings, it
> looks like the chipset doesn't actually support jumbo packets. Can't
> seem to find anything specifically on the Broadcom website though.
>
> http://www.smallnetbuilder.com/content/view/30549/75/1/1/
>
> (See the comment:
> "Updated 8/18/2008
> QNAP responded that the Broadcom BCM5787 does not support jumbo frames.
> But they chose it because it had the best throughput of the chipsets
> they evaluated. ")
>
> Robert.
>
> -----Original Message-----
> From: Robert Craig
> Sent: Monday, February 09, 2009 11:46 AM
> To: 'post21761@community.qnx.com'
> Subject: RE: Success (Almost)
>
> Hi Kevin:
> I've looked through the source and there's bad news on the
> Jumnbo packet front. It looks like Jumbo packet usage is restricted to
> only a certain variety of BCM chip IDs due to some sort of "chip set
> quirks". I'll take a closer look into the NetBSD source to see why this
> would be the case, but the behaviour that you're seeing is expected...
>
> In terms of nicinfo, this is also expected. We hooked in some plumbing
> to nicinfo to provide basic feedback for NetBSD style drivers (packet
> counts essentially), but the output is by no means complete.
> "ifconfig"
> (or ifconfig -v) for these drivers generally provides equivalent (and
> in
> some cases better) output.
>
> I'm not sure about the initial timeouts (I'll take a look). The second
> timeout (with netmanager) I THINK makes sense since it will try and
> bring up the interface and wait for DHCP to fail before it continues.
> I
> belive that you can get around this by marking the interface as
> disabled
> in the network configuration manager.
>
>
> R.
>
> -----Original Message-----
> From: KEvin Raymond [mailto:community-noreply@qnx.com]
> Sent: Monday, February 09, 2009 10:27 AM
> To: drivers-networking
> Subject: Success (Almost)
>
> Hello Robert,
>
> Thanks for all your suport so far. I was testing the driver this
> morning
> and can confirm that it did work, however I saw a coule of things which
> you will probably want to know about.
>
> 1st. The MTU canot be changed to a value larger than 1500. I was hoping
> to use ~8000 for the camera I will need to interact with. No the end of
> the world, but it would be nice to get working.
>
> 2nd. There is still a large hang on bootup or starting the driver, but
> it only occurs if there is noactive network cable connected to the
> broadcom nic. We saw this because only one of the dual onboard nics was
> connected. Again this is not the end of the world, we can diable in the
> bios the nic that we son't be using. Please refer to the attached
> ssloginfo dumps to see exactly why there is a delay. I added in some
> comments to help identify exactly where they are.
>
> 3rd. Some of the info displayed by nicinfo was incorrect. the MTU seems
> to be correct with 1500, bu the MRU should be greater than 0.
>
> Please take a look
>
> bge0:
> Broadcom Gigabit Ethernet Controller
>
> Physical Node ID ........................... 00187D 03F4D4
> Current Physical Node ID ................... 00187D 03F4D4
> Current Operation Rate ..................... 1000.00 Mb/s full-duplex
> Active Interface Type ...................... MII
> Active PHY address...
View Full Message
|
|
|
|
|
|
02/09/2009 1:10 PM
post21792
|
Hi Kevin:
I've been looking at the "large hang at bootup", and I haven't
been able to reproduce it. I've got the same sort of setup as you (two
on board nics) and things go through smoothly even though the second NIC
isn't plugged in.
Just to make sure that you've got a clean driver build, I've attached
the same driver binary that I was using for testing on my board.
Can you delete /etc/net.cfg (the file created by the network
configuration tool) and, when the OS boots, and says "Press the space
bar ..." can you press the space bar and hit F6 4 times and then let me
know where the delays kick in and for how long?
Thanks
Robert.
-----Original Message-----
From: KEvin Raymond [mailto:community-noreply@qnx.com]
Sent: Monday, February 09, 2009 10:27 AM
To: drivers-networking
Subject: Success (Almost)
Hello Robert,
Thanks for all your suport so far. I was testing the driver this morning
and can confirm that it did work, however I saw a coule of things which
you will probably want to know about.
1st. The MTU canot be changed to a value larger than 1500. I was hoping
to use ~8000 for the camera I will need to interact with. No the end of
the world, but it would be nice to get working.
2nd. There is still a large hang on bootup or starting the driver, but
it only occurs if there is noactive network cable connected to the
broadcom nic. We saw this because only one of the dual onboard nics was
connected. Again this is not the end of the world, we can diable in the
bios the nic that we son't be using. Please refer to the attached
ssloginfo dumps to see exactly why there is a delay. I added in some
comments to help identify exactly where they are.
3rd. Some of the info displayed by nicinfo was incorrect. the MTU seems
to be correct with 1500, bu the MRU should be greater than 0.
Please take a look
bge0:
Broadcom Gigabit Ethernet Controller
Physical Node ID ........................... 00187D 03F4D4
Current Physical Node ID ................... 00187D 03F4D4
Current Operation Rate ..................... 1000.00 Mb/s full-duplex
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 0
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
Packets Transmitted OK ..................... 878
Bytes Transmitted OK ....................... 124790
Multicast Packets Transmitted OK ........... 0
Packets Received OK ........................ 4475
Bytes Received OK .......................... 491499
Multicast Packets Received OK .............. 3847
bge1:
Broadcom Gigabit Ethernet Controller
Physical Node ID ........................... 00187D 03F4D5
Current Physical Node ID ................... 00187D 03F4D5
Current Operation Rate ..................... 0 kb/s
Active Interface Type ...................... Unknown
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 0
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
Packets Transmitted OK ..................... 35
Bytes Transmitted OK ....................... 5530
Multicast Packets Transmitted OK ........... 0
Packets Received OK ........................ 0
Bytes Received OK .......................... 0
Multicast Packets Received OK .............. 0
I will be testing the NICs soon when they have a lot of traffic on them
and give you feedback on that.
Again, thanks for all your help, your support has been amazing.
Kevin
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post21761
|
|
|
|
|
|
02/10/2009 10:28 AM
post21889
|
Hello Robert,
I have been rebooting the machine with different configurations on the NICs (DHCP vrs static, unplugged vrs plugged). I
ran the boot in verbose mode as you suggested and was finding that it was hanging when it is trying to mount Qnet.
If there is only one connected and it is Gigabit, then it did not have a problem, however one connected at 100 megabit
causes a hang.
I'm happy with the way the driver is performing and I thank you for all the effort you've put into this, I would not
worry about the delays on booting.
Thanks,
Kevin
> Hi Kevin:
>
> I've been looking at the "large hang at bootup", and I haven't
> been able to reproduce it. I've got the same sort of setup as you (two
> on board nics) and things go through smoothly even though the second NIC
> isn't plugged in.
>
> Just to make sure that you've got a clean driver build, I've attached
> the same driver binary that I was using for testing on my board.
>
> Can you delete /etc/net.cfg (the file created by the network
> configuration tool) and, when the OS boots, and says "Press the space
> bar ..." can you press the space bar and hit F6 4 times and then let me
> know where the delays kick in and for how long?
>
> Thanks
> Robert.
>
|
|
|
|
|
|
02/10/2009 10:36 AM
post21891
|
Glad that everything's working out with the new driver. It was a useful
effort considering the bug that it uncovered!
I'll continue looking into the driver delays on boot up since I'm sure
that someone will take issue with this at some point in time ;>.
Robert.
-----Original Message-----
From: KEvin Raymond [mailto:community-noreply@qnx.com]
Sent: Tuesday, February 10, 2009 10:28 AM
To: drivers-networking
Subject: Re: RE: Success (Almost)
Hello Robert,
I have been rebooting the machine with different configurations on the
NICs (DHCP vrs static, unplugged vrs plugged). I ran the boot in verbose
mode as you suggested and was finding that it was hanging when it is
trying to mount Qnet.
If there is only one connected and it is Gigabit, then it did not have a
problem, however one connected at 100 megabit causes a hang.
I'm happy with the way the driver is performing and I thank you for all
the effort you've put into this, I would not worry about the delays on
booting.
Thanks,
Kevin
> Hi Kevin:
>
> I've been looking at the "large hang at bootup", and I haven't
been
> able to reproduce it. I've got the same sort of setup as you (two on
> board nics) and things go through smoothly even though the second NIC
> isn't plugged in.
>
> Just to make sure that you've got a clean driver build, I've attached
> the same driver binary that I was using for testing on my board.
>
> Can you delete /etc/net.cfg (the file created by the network
> configuration tool) and, when the OS boots, and says "Press the space
> bar ..." can you press the space bar and hit F6 4 times and then let
> me know where the delays kick in and for how long?
>
> Thanks
> Robert.
>
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post21889
|
|
|
|
|
|
02/10/2009 10:51 AM
post21893
|
> hanging when it is trying to mount Qnet.
This is almost certainly because qnet causes the
_init routine of the driver to be called for the
first time, which causes the media link
auto-negotiation to occur.
--
aboyd
|
|
|
|
|
|
02/10/2009 1:55 PM
post21919
|
Very strange indeed. I have exactly the same cards as you in my machine
and they both run through the boot up without any hangs at all (with /
without QNET starting, with / without being connected or at 100BaseT).
Out of curiosity, how long are the delays (are we talking several
seconds, or 10s of seconds)?
I'll probably have to wait until someone complains and sends us hardware
to reproduce it, but that's OK.
Thanks for the testing,
Robert.
-----Original Message-----
From: KEvin Raymond [mailto:community-noreply@qnx.com]
Sent: Tuesday, February 10, 2009 10:28 AM
To: drivers-networking
Subject: Re: RE: Success (Almost)
Hello Robert,
I have been rebooting the machine with different configurations on the
NICs (DHCP vrs static, unplugged vrs plugged). I ran the boot in verbose
mode as you suggested and was finding that it was hanging when it is
trying to mount Qnet.
If there is only one connected and it is Gigabit, then it did not have a
problem, however one connected at 100 megabit causes a hang.
I'm happy with the way the driver is performing and I thank you for all
the effort you've put into this, I would not worry about the delays on
booting.
Thanks,
Kevin
> Hi Kevin:
>
> I've been looking at the "large hang at bootup", and I haven't
been
> able to reproduce it. I've got the same sort of setup as you (two on
> board nics) and things go through smoothly even though the second NIC
> isn't plugged in.
>
> Just to make sure that you've got a clean driver build, I've attached
> the same driver binary that I was using for testing on my board.
>
> Can you delete /etc/net.cfg (the file created by the network
> configuration tool) and, when the OS boots, and says "Press the space
> bar ..." can you press the space bar and hit F6 4 times and then let
> me know where the delays kick in and for how long?
>
> Thanks
> Robert.
>
_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post21889
|
|
|
|
|
|