Re: Questions about a self powered USB Hub


"Walter Wall" <me@xxxxxxxxxxx> wrote in message
news:48118c09_1@xxxxxxxxxxxxxxxxxxxxxxxxx

[Snipped for brevity]

I have to say that I have followed M.I.5.75's (how do you get a 3/4
symbol?) responses to many USB and Firewire problems both on this
newsgroup and the many others, and it would seem that he (like myself)
does have a good knowledge of the subject - and it's certainly better than
yours. His first two responses to the OP were accurate in every regard.
Yours was completely irrelevant to his problem (and wrong).

I have to deal with even more esoteric bus systems than just a simple USB
system every day. We have a larger than average USB bus system here -
mainly custom built test equipment, but with other devices. Parts of it
are entirely USB1.1 (with USB1 hubs) and connected to the rest of the USB2
system. The decision to use USB was taken at a time when firewire
chipsets were extremely expensive (and is, of course, the raison d'etre
for USB in the first place). It operates without problem and certainly
little observable bandwidth impact from the USB1.1 items (of which there
are 12).

Your last post is somewhat rambling and largely contradictory. But on a
fundamental level M.I.5.75 is mainly correct. The apparent bandwidth
problems do not limit the USB speed to any appreciable effect largely
because all the talking generally happens at diferent times.

You picked an unfortunate example of a single 12 Mb/s webcam and a 480
Mb/s disk drive on a singe USB2 single TT hub killing the bandwidth for
all other devices. Bad example and totally wrong. The single 12 Mb/s
device on the hub won't affect the bandwidth at all for any other 480 Mb/s
device preciselyy because the 12 Mb/s bandwidth limit is shared equally
between the - erm - single webcam. The 480 Mb/s devices are totally
unaware of it and unaffected by it, because they are downstream of the bit
that up converts the 12 Mb/s to 480 Mb/s. As M.I5.75 (and you) pointed
out, connecting other 12 Mb/s devices to the same single TT hub requires
that 12 Mb/s bandwidth to be shared, but in practice it doesn't have to be
shared often enough to slow things down appreciably. While the other
devices are dormant, the full bandwidth is available for those devices
that do wish to talk. The requirement to share to any extent is in fact
rare enough that it doesn't have much effect.

Connecting a 1.5 Mb/s device would appear to slow the HUB internal
bandwidth to a greater extent, but if you think about it long enough, you
just might realise that 1.5 Mb/s devices are limited to things like
keyboards and mice which talk over their USB bus very very occasionally in
bus bandwidth terms (I mean: how fast do you type?). They are thus of
practically no significance whatsoever in terms of limiting the hub
bandwidth.

M.I.5.75's allusion to the ethernet bus was in fact a very good one.
Ethernet (as you may (or may not) know) is a completely free for all
system. When a PC wants to talk on the bus, it just does. If it happens
to try this at the same time as one, some or all of the other PCs, then
all the talking PCs detect this (called a bus collision) and try again at
some random time later, hoping that by some quirk of luck that they are a
lone voice. This haphazard scheme would, on the face of it, seem to slow
the ethernet system to the point of unusability when more than a few PCs
are connected to it (and indeed the Xerox corporation were actually
convinced that that was going to happen as the system got bigger).
However, it didn't. Thousands of PCs can share a single Ethernet bus
system without any really noticeable depreciation in bandwidth.

And that's the fact of the matter. Although there would appear to be
appreciable bandwidth limitation in theory, it just doesn't occur in
practice.


The allusion that I had in mind at this point was the one contained in the
gospel according to St. Matthew Chapter 4 Verse 6

http://bible.cc/matthew/7-6.htm


.

Relevant Pages

  • Re: Scanner to USB 1.1 or 2.0 - speed ?
    ... USB 1.1 has a maximum transfer rate of 12 Mb/s. ... The average will not be as high as the peak, but I might expect it to be half the peak, so say 0.6 MB/s. ... If the scan is taking much over 20 s when transferring a 12 MB file, then it is not being limited by the USB bus, but by some other mechanism. ...
    (comp.periphs.scanners)
  • Re: Multiple USB 1.1 devices in USB 2 Hub speed ?
    ... get the full 12MB/s of each USB 1.1 device via the USB 2 link to a ... you don't get the 12 MB/s for each device. ... The 12 Mbps is the bit speed, it is not the actual bandwidth ... Usually devices consume more less than that. ...
    (comp.arch.embedded)
  • ohci_hcd, usb scanner and kernel 2.6.8.1 or 2.6.10 troubles
    ... Powering on scanner (usb hub unplugged, ... 0001, 12 Mb/s ... roothub.portstatus = 0x00100103 PRSC PPS PES CCS ... controller (state 0x8 ...
    (Linux-Kernel)
  • Re: Thunderbolt? (was: Light-peak)
    ... has been added...but that Intel also claims that copper will be also ... That overhead is the reason why Firewire has always been better then USB. ... continue to "brute force" add more bandwidth, ... Andrew J. Brehm ...
    (comp.sys.mac.advocacy)
  • Re: Thunderbolt? (was: Light-peak)
    ... has been added...but that Intel also claims that copper will be also ... That overhead is the reason why Firewire has always been better then USB. ... continue to "brute force" add more bandwidth, ... "Apple going it alone" scenario risk. ...
    (comp.sys.mac.advocacy)