5 ms·

Still Ethernet via USB 2.0, which means it is not actually gigabit.

by api 9y ago

dijit 9y ago
(and taking power away from the CPU). FWIW if you need gigabit you can get it on the (now old) cubietruck 3, which is an excellent SBC and even has a SATA controller.
chopin 9y ago
I am using a BananaPi for this. It also has a SATA port which makes it handy for a NAS. Processor and RAM are also a good bang for the buck.
- FullRetard 9y ago
  What is your experience with platform support (linux) with the BananaPi?
  - chopin 9y ago
    For my purposes, very good. There is a Raspi equivalent image and, afair, a Bananian image. I used the former on my first BananaPi (this runs my NAS). The latter runs a BananaPi I have used as a secondary ADS server (now it serves only as DNS, as I switched all desktops to Linux, see discussion https://news.ycombinator.com/item?id=16582231 https://news.ycombinator.com/item?id=16582231 as to why). Both run smoothly. EDIT: I should say (that's independent whether you use Raspberry or BananaPi) that both run for months without intervention. The only thing I found to be important is a good power source. I had frequently file system errors due to dying (somewhat cheap) chargers used as power source. I finally got a switched 50W multi charger (10 outlets á 2A) which I connected all Raspis and Bananas to. Since then, everything works pretty smooth.
poizan42 9y ago
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.

Still Ethernet via USB 2.0, which means it is not actually gigabit.

by api 9y ago

Still Ethernet via USB 2.0, which means it is not actually gigabit.

(and taking power away from the CPU). FWIW if you need gigabit you can get it on the (now old) cubietruck 3, which is an excellent SBC and even has a SATA controller.

chopin 9y ago

I am using a BananaPi for this. It also has a SATA port which makes it handy for a NAS. Processor and RAM are also a good bang for the buck.

FullRetard 9y ago
What is your experience with platform support (linux) with the BananaPi?
- chopin 9y ago
  For my purposes, very good. There is a Raspi equivalent image and, afair, a Bananian image. I used the former on my first BananaPi (this runs my NAS). The latter runs a BananaPi I have used as a secondary ADS server (now it serves only as DNS, as I switched all desktops to Linux, see discussion https://news.ycombinator.com/item?id=16582231 https://news.ycombinator.com/item?id=16582231 as to why). Both run smoothly. EDIT: I should say (that's independent whether you use Raspberry or BananaPi) that both run for months without intervention. The only thing I found to be important is a good power source. I had frequently file system errors due to dying (somewhat cheap) chargers used as power source. I finally got a switched 50W multi charger (10 outlets á 2A) which I connected all Raspis and Bananas to. Since then, everything works pretty smooth.

poizan42 9y ago

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.