5 ms·

I also noticed that. It's only ~280 megabits so seems a bit dishonest to call it gigabit. I guess what they mean is "gigabit ethernet standard" i.e. 1000BASE-T.

I also noticed that. It's only ~280 megabits so seems a bit dishonest to call it gigabit. I guess what they mean is "gigabit ethernet standard" i.e. 1000BASE-T. Also how does it act once its internal receive buffer is full? Is it possible to get the sender to slow down, or does it have to start dropping frames? Will important things such as ARP broadcasts and DHCP requests just risk getting lost?

zaarn 9y ago
When the internal receiver buffer is full, you drop the frames. Basically any protocol out there has some way of dealing with dropped packets (including UDP's "don't care") DHCP requests are usually repeated several times for this reason, the first one can get lost (this can and will happen even on a clean and underloaded gigabit homenetwork)
- poizan42 9y ago
  Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time) Traffic shaping on higher layers usually lets some packages deemed important through while dropping bulk traffic, tcp which is usually used for bulk transfers backs down when packages gets dropped, but that only gets you so far if you keep getting hammered with new connections or the sender acts maliciously.
  - zaarn 9y ago
    >Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time) Not if, it does. The repeats are usually good enough to get into the receiving buffer. If there is constant noise on the interface that it even interferes with basic protocol operation you're probably running something that doesn't know how to throttle the connection properly. Those things are usually best retrofitted with some form of ratelimiting in the kernel. But yes, in this case you wouldn't be able to do DHCP or ARP. This is also true for any further hops on the network. If the receive buffer is full there isn't much you can do about it other than try again later. And "try again later" is purely a protocol decision. On an internal network the fix is usually to have a Switch that can ratelimit a peer. Otherwise, there is no protection and you can easily replicate the effect by taking an old switch and patching up a loop. The resulting packet storm can easily shut down larger networks. On the larger internet, the telco's and ISPs are largely responsible for making sure their receive buffer doesn't get full.
vardump 9y ago
Probably it supports L2 pause frames (type of flow control) just like nearly any other ethernet device?
- poizan42 9y ago
  Thanks, I suspected something like that existed. Edit: The Wikipedia article says: "By 1999, several vendors supported receiving pause frames, but fewer implemented sending them.[4][5] Pause frames have several disadvantages.". Any idea what the situation is like today?
  - vardump 9y ago
    I believe L2 flow control is pretty common. Of course you're usually not going to see them even when using Wireshark etc., because they're handled at the MAC hardware level. I'm not aware how to reliably determine whether link partner has L2 flow control / pause frames enabled. But at least you can check whether it's locally enabled: Linux: ethtool -a eth0 macOS: ifconfig en0 | grep media Windows Powershell: Get-NetAdapterAdvancedProperty Alternatively you can check Control Panel / Network Connections / right click adapter + select Properties / click Configure / Advanced tab / Flow Control value. Note that above only applies to wired ethernet, not wlan.
pmyteh 9y ago
There is nothing dishonest about their announcement: they are explicit that speed is limited by the USB bus: > While the USB 2.0 connection to the application processor limits the available bandwidth, we still see roughly a threefold increase in throughput compared to Raspberry Pi 3B. Followed by a table showing 315Mb/s bandwidth, three times that of the 3B but a third that of full-speed Gigabit. And this isn't tucked away in a footnote, it's up front in the middle of the article.
- poizan42 9y ago
  The article yes, not the technical specification chart that is probably what most people see before buying it.
  - deleted 9y ago
    [deleted]
  - pmyteh 9y ago
    The product page, which is probably what most people see before buying it, simply says 'faster Ethernet': > 1.4GHz 64-bit quad-core processor, dual-band wireless LAN, Bluetooth 4.2/BLE, faster Ethernet, and Power-over-Ethernet support (with separate PoE HAT) I'm a bit cross because of the casual assumption of bad faith, when it seems to me they've gone to some effort to do the opposite: make the limitations clear instead of relying on a buzzword.

zaarn 9y ago

When the internal receiver buffer is full, you drop the frames. Basically any protocol out there has some way of dealing with dropped packets (including UDP's "don't care") DHCP requests are usually repeated several times for this reason, the first one can get lost (this can and will happen even on a clean and underloaded gigabit homenetwork)

poizan42 9y ago
Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time) Traffic shaping on higher layers usually lets some packages deemed important through while dropping bulk traffic, tcp which is usually used for bulk transfers backs down when packages gets dropped, but that only gets you so far if you keep getting hammered with new connections or the sender acts maliciously.
- zaarn 9y ago
  >Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time) Not if, it does. The repeats are usually good enough to get into the receiving buffer. If there is constant noise on the interface that it even interferes with basic protocol operation you're probably running something that doesn't know how to throttle the connection properly. Those things are usually best retrofitted with some form of ratelimiting in the kernel. But yes, in this case you wouldn't be able to do DHCP or ARP. This is also true for any further hops on the network. If the receive buffer is full there isn't much you can do about it other than try again later. And "try again later" is purely a protocol decision. On an internal network the fix is usually to have a Switch that can ratelimit a peer. Otherwise, there is no protection and you can easily replicate the effect by taking an old switch and patching up a loop. The resulting packet storm can easily shut down larger networks. On the larger internet, the telco's and ISPs are largely responsible for making sure their receive buffer doesn't get full.

vardump 9y ago

Probably it supports L2 pause frames (type of flow control) just like nearly any other ethernet device?

poizan42 9y ago
Thanks, I suspected something like that existed. Edit: The Wikipedia article says: "By 1999, several vendors supported receiving pause frames, but fewer implemented sending them.[4][5] Pause frames have several disadvantages.". Any idea what the situation is like today?
- vardump 9y ago
  I believe L2 flow control is pretty common. Of course you're usually not going to see them even when using Wireshark etc., because they're handled at the MAC hardware level. I'm not aware how to reliably determine whether link partner has L2 flow control / pause frames enabled. But at least you can check whether it's locally enabled: Linux: ethtool -a eth0 macOS: ifconfig en0 | grep media Windows Powershell: Get-NetAdapterAdvancedProperty Alternatively you can check Control Panel / Network Connections / right click adapter + select Properties / click Configure / Advanced tab / Flow Control value. Note that above only applies to wired ethernet, not wlan.

pmyteh 9y ago

There is nothing dishonest about their announcement: they are explicit that speed is limited by the USB bus: > While the USB 2.0 connection to the application processor limits the available bandwidth, we still see roughly a threefold increase in throughput compared to Raspberry Pi 3B. Followed by a table showing 315Mb/s bandwidth, three times that of the 3B but a third that of full-speed Gigabit. And this isn't tucked away in a footnote, it's up front in the middle of the article.

poizan42 9y ago
The article yes, not the technical specification chart that is probably what most people see before buying it.
- deleted 9y ago
  [deleted]
- pmyteh 9y ago
  The product page, which is probably what most people see before buying it, simply says 'faster Ethernet': > 1.4GHz 64-bit quad-core processor, dual-band wireless LAN, Bluetooth 4.2/BLE, faster Ethernet, and Power-over-Ethernet support (with separate PoE HAT) I'm a bit cross because of the casual assumption of bad faith, when it seems to me they've gone to some effort to do the opposite: make the limitations clear instead of relying on a buzzword.