which out of these two cables/ports is best for my miniDV camcorder?

Ilya Zakharevich wrote:
[A complimentary Cc of this posting was sent to
Peter D
[email protected]], who wrote in article :
In real life USB maximum transfers peak at about 2/3 of that speed. If you
research actual test results, you'll often see speeds max out at 1/3 of the
max of 480 Mbps. Becasue USB creates a network where every device "chats'
with the central "host" (the computer in most cases) USB 2.0 requires more
CPU prcesses than

... Sorry, but the *technical contents* of this is exactly 0. If you
know WHY the throughput is not close to the theoretical maximum,
please explain. If you do not - we all ALREADY know that it is not
close to the theoretical maximum; do you see any reason to repeat this
statement again?

Thanks,
Ilya

He DID. Perhaps you could read it again.

On Sun, 20 Jan 2008 10:10:31 -0600, "Peter D" [email protected] wrote in
:

USB 2.0 (aka USB Hi-Speed) is technically faster (480Mbps) than Firewire 400
(400Mbps).

That's raw speed, which is relatively meaningless.

In real life USB maximum transfers peak at about 2/3 of that speed. If you
research actual test results, you'll often see speeds max out at 1/3 of the
max of 480 Mbps.

That actually varies widely, a function of the USB transfer type and
signaling rate, in addition to source and target device characteristics.

Becasue USB creates a network where every device "chats'
with the central "host" (the computer in most cases) USB 2.0 requires more
CPU prcesses than Firewire and the more peripherals that are connected and
in use the slower the USB network.

The "host" is both the USB host controller and the host computer.
http://www.usb.org/developers/usbfaq/

USB's actual throughput is a function of many variables. Typically,
the most important ones are the target device's ability to source or
sink data, the bandwidth consumption of other devices on the bus, and
the efficiency of the host's USB software stack. In some cases, PCI
latencies and processor loading can also be critical.

When more devices are active on a given USB bus, total bus throughput
tends to go up. The problem is that latency for any given device tends
to go up as well.

So avoid situations where you are
transferring from a USB device to a USB device (USB scanner to USB external
HD, USB camcorder to USB HD). Always transfer from a single USB device to a
non-USB device if possible.

Most computers have at least two USB ports, and the most important thing
is to put slow devices on one port, and fast devices on another port.

Since USB doesn't support device to device transfers, transferring data
between two devices consumes double the amount of bus bandwidth in
addition to host overhead; i.e., device 1 to host, and host to device 2,
although the impact is greatly reduced if the two devices are on
different USB ports. This usually isn't an issue with digital video.

And don't forget that if you have a USB keyboard
and/or mouse connected you don't have a single device on the USB bus. Evbery
time you use the mouse or keyboard, you slow the network.

More accurately, you increase latency for other devices on the same bus
by utilizing the bus.

Firewire comes in two flavours. The original Firewire 400/IEEE1394(a) (100,
200, or 400 Mbps) and new Firewire 800/IEEE1394b (800Mbps). There's also a
'new' 3200 Mbps standard on the way. Actual speed is much closer to
technical speed, and faster and more reliable than USB. Why? Because of the
design. As well as significant design improvements that enhance and improve
efficiency through hardware implementation and control, Firewire allows each
device to control the network and each device can "speak" directly to
another without the need for a central "host". This significantly reduces
CPU load and increases transfer rates. Real life transfer rates on Firewire
are typically 90% of the max technical speed. Even poorly
configured/implemented Firewire can run at 80% of max speed.

The bigger issue for video transfer is reduced latency. There's more
than enough bandwidth with either USB or Firewire.

Why Firewire is better than USB for Video:
As well as the significant real life speed improvement of Firewire over USB,
Firewire is also much better at sustained throughput, reducing (in fact in
most cases eliminating) dropped frames commonly seen in USB transfers.

That's because of bus latency.

A real test you can try:
Without doing anything else on the computer, transfer 5 minutes of video
using USB 2.0 and then Firewire and count the dropped frames. Now do it
again while using the computer (surf the net, type a letter, typical use
stuff). Now compare the droppped frames. I think you'll settle on Firewire.

Some sources:
http://en.wikipedia.org/wiki/USB
http://en.wikipedia.org/wiki/FireWire

--
Best regards,
John Navas
Panasonic DMC-FZ8 (and several others)

On Sat, 19 Jan 2008 19:08:25 +0000 (UTC), Ilya Zakharevich
wrote in :

[A complimentary Cc of this posting was sent to
John Navas
], who wrote in article :
The primary issue, as I've noted previously, is not speed, but that
Firewire is designed for continuous independent bus transfers, whereas
USB 2.0 is not, with all USB transfers controlled by the host by means
of polling. That can result in small USB transfer pauses when the host
gets busy. (Ever notice how a USB mouse pointer will sometimes move
erratically?)

No. I do not see how the effect you describe can appear; device
drivers should not be affected by the "system being busy"; an
interrupt is an interrupt is an interrupt. I may be missing more
technical details...

The USB bus isn't interrupt-driven -- it's polled (as I wrote), which is
why latency can be an issue. When the host is busy servicing device 1,
device 2 has to wait until the host is free (latency), which can be a
problem when streaming at high speed, as in the case of video. The part
you snipped on polling:

This is no problem with, say, a disk drive, or even a DVD burner
(given underrun protection), but when digital video is being streamed
there's often no good way to pause the stream, so when the host gets
busy, data can be lost. USB 3.0 is supposed to address this issue,
but how well it will work in practice is an open question.

--
Best regards,
John Navas
Panasonic DMC-FZ8 (and several others)

[A complimentary Cc of this posting was sent to
John Navas
], who wrote in article :
No. I do not see how the effect you describe can appear; device
drivers should not be affected by the "system being busy"; an
interrupt is an interrupt is an interrupt. I may be missing more
technical details...

The USB bus isn't interrupt-driven -- it's polled (as I wrote),

Do not see any significant difference. The poller would set up a
wake-up call, which would generate an interrupt. [And, BTW, why my
PCI hardware view shows that USB controllers use interrupts?]

which is why latency can be an issue.

Could you explain how latency is related to polling?

When the host is busy servicing device 1,
device 2 has to wait until the host is free (latency), which can be a
problem when streaming at high speed, as in the case of video.

I do not see how this could be a problem - just do not use more than 1
USB device...

The part you snipped on polling:

[part with no relation to polling (???!!!) skipped.]

Puzzled,
Ilya

On Mon, 21 Jan 2008 15:46:26 +0000 (UTC), Ilya Zakharevich
wrote in :

[A complimentary Cc of this posting was sent to
John Navas
], who wrote in article :
No. I do not see how the effect you describe can appear; device
drivers should not be affected by the "system being busy"; an
interrupt is an interrupt is an interrupt. I may be missing more
technical details...

The USB bus isn't interrupt-driven -- it's polled (as I wrote),

Do not see any significant difference. The poller would set up a
wake-up call, which would generate an interrupt. [And, BTW, why my
PCI hardware view shows that USB controllers use interrupts?]

When the bus is busy with device 1, device 2 has to wait until device 1
is done. In addition, device 2 cannot use the bus until polled by the
host bus controller, which can be delayed for a number of reasons.
There is no instantaneous interrupt response.

which is why latency can be an issue.

Could you explain how latency is related to polling?

Latency occurs because the device has to wait to be polled. It cannot
demand the bus instantly.

When the host is busy servicing device 1,
device 2 has to wait until the host is free (latency), which can be a
problem when streaming at high speed, as in the case of video.

I do not see how this could be a problem - just do not use more than 1
USB device...

That helps, but there can still be latency due to issues in the host
controller (which handles multiple ports) and software stack (which
handles all ports).

--
Best regards,
John Navas
Panasonic DMC-FZ8 (and several others)

Ilya Zakharevich writes:

The USB bus isn't interrupt-driven -- it's polled (as I wrote),

Do not see any significant difference. The poller would set up a
wake-up call, which would generate an interrupt. [And, BTW, why my
PCI hardware view shows that USB controllers use interrupts?]

More likely, the poller would set a wakeup call, which would add an
entry into a timer queue somewhere. The timer interrupts regularly,
and when the specified time has elapsed, the process that asked for the
wakeup is scheduled to run again. But it would need to wait for CPU
resources to do anything. It's unlikely to be called directly from the
timer interrupt handler.

Dave

"Ilya Zakharevich" wrote in message
...
[A complimentary Cc of this posting was sent to
Peter D
[email protected]], who wrote in article :
In real life USB maximum transfers peak at about 2/3 of that speed. If
you
research actual test results, you'll often see speeds max out at 1/3 of
the
max of 480 Mbps. Becasue USB creates a network where every device "chats'
with the central "host" (the computer in most cases) USB 2.0 requires
more
CPU prcesses than

... Sorry, but the *technical contents* of this is exactly 0.

You say that as if I shold care what you think. If you have Paypal, send me
a quarter. I'll call you the moment I care. :-)

If you know WHY the throughput is not close to the theoretical maximum,
please explain.

It's all there. I assume English isn't your first language. So here goes:
The theoretical bandwith (400Mbit/sec) relies on perfect cable length,
perfect cable materials, and perfect hardware acting perfectly while doing
nothing else. The reality is that cables are not perfect, voltage and
signals on the line(s) are not perfect, connectors are not perfect, hardware
is not dedicated, and more than one item on the USB 'network' degrades
performance. Multiple items (even if not in use) degrade performance even
further. USB is inherently "busy" and "chatty". And that makes it useless
for Vidoe transfer if Firewire is available.
HTH

[A complimentary Cc of this posting was sent to
Peter D
[email protected]], who wrote in article :
If you know WHY the throughput is not close to the theoretical maximum,
please explain.

It's all there.

yeah, right...

The theoretical bandwith (400Mbit/sec) relies on perfect cable length,
perfect cable materials, and perfect hardware acting perfectly while doing
nothing else.

If it were so, how would this differ from Firewire? And since using
better cables and hardware which does nothing else DOES NOT improve
the USB throughput, I do not think this is a correct explanation.

and more than one item on the USB 'network' degrades performance.

Why do you repeat this BS? Having a dedicated USB controller does not
let performance to be anywhere close to the theoretical maximum.

further. USB is inherently "busy" and "chatty". And that makes it useless
for Vidoe transfer if Firewire is available.

Year, right! Now a presence of Firewire starts to influence USB
performance...

Again: if you know some real technical info, please let us know,
Ilya

[A complimentary Cc of this posting was sent to
John Navas
], who wrote in article :
The USB bus isn't interrupt-driven -- it's polled (as I wrote),

Do not see any significant difference. The poller would set up a
wake-up call, which would generate an interrupt. [And, BTW, why my
PCI hardware view shows that USB controllers use interrupts?]

When the bus is busy with device 1, device 2 has to wait until device 1
is done.

Irrelevant. Assume there is no device 1. Why maximum throughput is
not achieved?

In addition, device 2 cannot use the bus until polled by the
host bus controller, which can be delayed for a number of reasons.
There is no instantaneous interrupt response.

There is if there is no higher-priority interrupt. Why would there?

Could you explain how latency is related to polling?

Latency occurs because the device has to wait to be polled. It cannot
demand the bus instantly.

Same happens with any communication method. If the other side does
not cooperate, a streaming device would choke - polling or no polling.

I do not see how this could be a problem - just do not use more than 1
USB device...

That helps, but there can still be latency due to issues in the host
controller (which handles multiple ports)

Assume than controller is dedicated to a device.

and software stack (which handles all ports).

Again, how this is relevant? The stack expects some data be ready on
port7 in 3msec. It sets a timer, and polls port7. If nothing there,
and some suitable delay passed, it can poll the remaining 11 ports.
(I assume that USB controller can bus master for multi-packet
transfer; can it?)

IMO, a *real* answer would describe a minimal (repeatable) pattern of
USB activity to transfer a 512byte packet from an USB device,
calculate the required timing, and show why this should take more than
16usec (to support the observed max of 33MB/sec). *Somebody* must
have done it already...

Thanks,
Ilya

[A complimentary Cc of this posting was sent to
Dave Martindale
], who wrote in article :
Do not see any significant difference. The poller would set up a
wake-up call, which would generate an interrupt. [And, BTW, why my
PCI hardware view shows that USB controllers use interrupts?]

More likely, the poller would set a wakeup call, which would add an
entry into a timer queue somewhere. The timer interrupts regularly,
and when the specified time has elapsed, the process that asked for the
wakeup is scheduled to run again. But it would need to wait for CPU
resources to do anything. It's unlikely to be called directly from the
timer interrupt handler.

AFAIK, with any sane OS, a device driver requiring wakeup would not
wait for scheduler. (The scheduler usually has too coarse granularity
- 1msec or above.)

Yours,
Ilya