10/100/1000 Mbps rated, so 1 Gbps is supported.
Auto MDI/MDIX supported, so you don't need a cross-over cable when
chaining together multiple switches or routers to this device. Good
because otherwise there could've been a problem with connecting your
router to this switch.
No wireless connects so nothing needs to be discussed about that (e.g.,
max bandwidth of, say, 54 Mbps for wireless versus 1 Gbps for wired).
No configuration, so forget the QoS question.
Automatic power reduction but no mention of idle detect, sleep, and
wakeup delays. Does mention it'll up the power output for longer cables
but that won't help on the other end to make the hosts up their power
for longer cables.
There's mention of supporting 9KB (15KB in their manual) jumbo frames
(instead of the old 1500KB frame) but I'm not sure Windows is going to
fluctuate its frame size based on some auto-negotiation with an upstream
device, plus it won't match what your ISP expects. If the frame size is
larger than can be handled at either end, you end up with layer 2
fragmentation or reassembly that causes delay. I haven't investigated
Windows 7 to see if it auto-negotiates to larger frame sizes but I know
Windows XP won't (you'll have to use a network tweaker but then the size
is fixed and won't match with your ISP). Whether or not the "store and
forward" mechanism of this switch forces the use of jumbo frames is not
clear from its manual or description, so maybe something like Wireshark
could tell you the frame size.
Alas, I didn't see mention that its port LEDs show negotiated speed by
using different colors. It just shows status regarding link/active.
"Fast Ethernet" means 100 Mbps (100BASE-TX) with backward compatibility
(usually auto-negotiated) with 10 Mbps (10BASE-TX). A NIC listed as
"Fast Ethernet" means it supports 10/100 Mbps, not 1000 Mbps. See
http://en.wikipedia.org/wiki/Fast_ethernet. For 1000 Mbps (1 Gbps),
you'd want something that identifies itself as Gigabit Ethernet; see
http://en.wikipedia.org/wiki/Gigabit_Ethernet.
I've seen a NIC detect a problem and auto-negotiate down to 10 Mbps
(from an initial connect of 100 Mbps) but which will not auto-negotiate
back up. That is, once the rate gets dirty and has to drop then it
stays there. I forget the typical culprits of having to lower the rate
but having to resend over some percentage of lost (unacknowledged)
packets is probably one cause.
Did you actually install a network card? If so, you should be able to
see a sticker with an actual model number instead of getting just some
specs detected within Windows. If not, is it an onboard NIC (i.e., a
backpanel RJ-45 connector from a controller on the motherboard)? In
that case, knowing the motherboard maker and model could help in
identifying just what specs its NIC controller can support.
Below is an example of an AddOn NIC that declares itself as a "Fast
Ethernet" device. Notice it never mentions 1000 Mbps (1 Gbps) because
it isn't a gigabit NIC.
http://www.addon-tech.com/new/product_info.php?id=76
Looks like you added the switch trying to get around the limitation of
the switch in the router. That is, you added a 10/100/1000 Mbps switch
so you weren't limited to the 10/100 Mbps switch in the router for
throughput between your intranet hosts. However, you need to perform
the additional step of getting better NICs in your intranet hosts. They
only have FastEther NICs which limits them to 10/100 Mbps maximum.
Can't really tell if that is for a daughtercard (a NIC card) or for a
controller on the motherboard. The controller on the motherboard is the
same one often used on a NIC card.
However, the anti-virus program is still going to interrogate all the
bytes for a newly created or modified file. That interrogation takes
time. Although you could disable the AV program, that doesn't always
work. Some AV programs will continue routing the network traffic
through their proxy or handler. Disabling just means the content won't
be interrogated but if there is a problem with the proxy or handler than
throughput remains affected. I had that problem way back when I used to
have Norton 2003 installed: disabling interrogation didn't eliminate the
problem of blocked traffic when their proxy went unresponsive so I had
to reboot to get it responsive again. As I recall with AVG, you have to
uninstall it to really get it out of the way.
Since you are testing throughput between intranet hosts, you could
disconnect the router (or power it off) during testing and uninstall AVG
(and other security software) on the source and target hosts. Reinstall
the security software after testing and before reconnecting the Internet
setup.
Well within the 100 m maximum for Ethernet, and capable cables, too.
Did you make sure the source and target hosts (and any other hosts
connected to the switch) were all quiescent? That is, with the router
disconnected or powered off, do you see any traffic over your intranet
going through the common switch? I don't know if your switch's LEDs
will blink when there is traffic or if you'll have to use a packet
sniffer, like Wireshark, to be sure.
Which makes me wonder if that new "feature" of jumbo frames is getting
in the way and causing fragmentation and reassembly (to generate 1500 B
frames expected by the host NICs). Alas, the description for this
switch says there is no user configurable settings to, say, disable the
jumbo frame feature or limit the frame size (so it matches your hosts).
http://www.bitplumber.net/2009/03/how-to-configure-jumbo-frames/
Notice the 3rd bullet that says, "You are sure all your host operating
systems and NIC drivers will support Jumbo Frames". I don't know that
just getting drivers that have jumbo frame support will fix your program
unless the hardware mentions it also supports larger frames. Probably
but maybe not.
Back in my Windows XP box, with the onboard NIC on the mobo, there is no
selection in the NIC properties to support jumbo frames. Some switches
let you enable/disable jumbo frame support but this switch is
non-configurable so I don't know what it might be doing with frame size.
Since it is a "store and forward" switch, it's possible it accumulates
the 1518 B packets to store them and then assembles them into jumbo-
sized frames which your other intranet host cannot handle directly.
Did you check if the NIC properties in Device Manager on your source and
target intranet hosts has a jumbo setting and that it's enabled?
