Being a Netgear product, it has a number of features that far too many manufacturers seem to leave out - for example, dual LED RJ45 jacks - one light for link/data on 100BaseT, the other for 10BaseT. The utilisation graphs for both 100Mbps and 10Mbps (and collision indicators for both segments) are extremely useful, and I've used them quite a bit for debugging. Also, as the case is steel rather than moulded plastic (cf Intel, for example), they are great hubs for around the lab, too.
I don't have the same problem with heat output as PhilSp - it is warm, but not 486 hot.
One thing that has bitten me in the past with these - there is a bridge chip inside (intelligent, or so Netgear would have you believe). This is obviously neccessary (what happens if all of your 100Mbps traffic gets put onto 10Mbps? Oops), but it doesn't neccessarily pass on ICMP error messages, so tracking network stack errors can be a little more entertaining than I'd like.
Really, the thing just sits on my desk and works - what more could I ask of it?
It still doesn't make the tea, though - perhaps I should swap it with PhilSp's...
In case you're interested : 10/100 hubs run the risk of losing both ICMP and UDP traffic if they travel 100 -> 10; This is because most
10/100 hubs provide a small speed-change-buffer, between the 100Mb/s bus and the 10Mb/s bus. TCP connections will retry and throttle back
if they need to - ICMP cannot do this, so the lost packet stays lost, UDP can only do this in software, so in many cases the packet also stays lost.
21.08.2001 19:36
In case you're interested : 10/100 hubs run the risk of losing both ICMP and UDP traffic if they travel 100 -> 10; This is because most 10/100 hubs provide a small speed-change-buffer, between the 100Mb/s bus and the 10Mb/s bus. TCP connections will retry and throttle back if they need to - ICMP cannot do this, so the lost packet stays lost, UDP can only do this in software, so in many cases the packet also stays lost.