Re: Why do not CRT/LCD monitors come with USB?

phil-news-nospam@xxxxxxxx writes:

On Sat, 26 Jul 2008 14:09:27 -0600 Joe Pfeiffer <pfeiffer@xxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx writes:
|
| Whether that's flaky is a matter of opinion -- the intent is that a
| non-savvy user can unplug a disk, plug it into a different port, and
| have the OS recognize it's the same disk. To do that, you have to
| decouple the device addressing from the port it's plugged into; once
| you've done that, there's no reason to treat same-port as a special
| case.

No you don't "have to decouple the device addressing from the port it's
plugged into". You can remap the referenced device address or name to
the changed physical address. This can be, and should be, done entirely
in the OS in a layer just _above_ the core layer of device drivers.

You're just decoupling in a different layer than USB is. I don't see
any particular advantage to either approach.

|> USB is not very graceful in hotplugging. It can't figure out what is going
|> on instantly. Firewire beats USB big time, and even Firewire is poor.
|
| Most of that time is just allowing the device to settle.

I see messages saying that. Maybe you can define what "settle" means.
The only time frame I see that is needed is for repeated connections
because the user is sloppy inserting the cable. There can be lots of
"connecting" and "disconnecting" of the same device. Once the device
stays connected for a fraction of a second, it should be good to go.
It can now send its basic identify information. Extended information,
such as how big the disk space is, can come later when the controller
in the device gets the drive up to speed. Once that message arrives,
then the OS can make the storage available to the storage subsystem.
In cases of drives that know their size even before the spin up, they
can report that immediately and the spin up can even be deferred until
first usage.

It's an issue of borderline-compliant devices. In this case, "settle"
means "finish booting so it is indeed able to identify itself"

| Because the old OHCI (and UHCI) devices didn't talk hi-speed. You'd
| have to ask Intel why they developed EHCI instead of a faster OHCI,
| but that's completely unrelated to your claim. A new driver was
| needed for a new interface chip.

What do you mean by "didn't talk hi-speed". Just talk faster.

Not if the chip doesn't talk that fast.

The fault here is that Intel designed OHCI (and even EHCI) in such a way that
the speed is integral to the protocol. I would not have designed it that way
at all. The way I would have designed it is there would be interrupts from
the controller whenever state changes occur. If the message gets to the device
faster in newer hardware, then its just less time between when the message is
sent and when the next message can be sent (aside from message queueing which
would really allow some finite but reasonably large queue of tagged messages).
The hardware would negotiate the point-to-point link speed. It can then be
reported to the software in sufficiently large fields to allow a huge range
of possibilities. And the basic need for the software to know the speed is
to report it in logging and such. Some finite subset of speeds would make
sense for the actual hardware interfaces. This can be defined in terms of
a set of speeds and "all multiples of X thereafter".

Would you mind explaining just how the protocol is different at higher
speeds, once the negotiation is complete?
.

Relevant Pages

  • Re: Digital switch over query
    ... Athlon XP2500+ cpu by which time, the original Debian install was ... Have you been able to see speeds nearer to 10MB/s rather ... The reduced cpu clock speed didn't seem to compromise the disk to disk ... USB/Firewire connected drives). ...
    (uk.tech.digital-tv)
  • Re: CD Burning? media and burner questions
    ... There are some burning programs and disk utilities that will ... speeds. ... CDA audio recorders record at 1x and you likely can't ...
    (rec.audio.pro)
  • Re: OOM killer gripe (was Re: What still uses the block layer?)
    ... not thrashing is that all of the pages in RAM are in the swap cache, ... used to be able to do 3 point something megabytes per second to/from disk, ... But swapping heavily has been a viable mode of operation ... speeds aren't keeping up with processor and memory increases. ...
    (Linux-Kernel)
  • Re: OOM killer gripe (was Re: What still uses the block layer?)
    ... used to be able to do 3 point something megabytes per second to/from disk, ... But swapping heavily has been a viable mode of operation ... speeds aren't keeping up with processor and memory increases. ... is about the I/O time of 512 bytes of contiguous disk data. ...
    (Linux-Kernel)
  • Re: very slow computer
    ... are the disk speeds the same? ... Replacing a 7200 rpm with a 5200 rpm (or ... How large is your hard disk and how ...
    (microsoft.public.windowsxp.newusers)