I added the bold part for clarity.
That was my point, what data or studies did EU conduct or get to determine they had a fix? Are there any?

Hi,

I am pretty sure that they were very careful about this and sent a Certified letter to Bozo the Clown to ask about the ramifications to making everything USB C, and he assured them it was a great idea so they did it (ha ha ha)

This is an interesting question and I can't find anything with a quick search, but I did find that it is not just about the e-waste it's also about standardizing and reducing market fragmentation. It makes it possible to use the same connector for almost everything including charging, video, etc., etc. Also, that it mostly affects Apple because all the others were going to be using the USB C standard already.

I didn't realize it until now that they are up to 80Gbps which is really amazing. It is questionable if we could get that kind of rate from another type of connector anyway.

What I like about it is that maybe in the near future everything will be USB C so we only need to worry about one type of cable, one type of port, one type of everything. This would also mean if you have both an Android phone and Apple phone you can use the same charger.
One of the problems I faced was when I went to stay with a friend of mine who is a big Apple phone fan. We could not share the same charger we had to have two different ones. That meant either different chargers or different cables or whatever. If we both could use USB C cables and/or chargers, it would have been a little simpler. That may not make e-waste any better, but it would make things simpler for the both of us.

 

Sigh

<sound: indistinct chatter>

What does that mean, that does not tell us anything.
You do have to realize that we all don't agree on everything all the time. That's ok though.

 

Hello,

From howtogeek:

The latest entries, USB 4.0, Thunderbolt 3, and Thunderbolt 4, are where you'll find the highest data transfer speeds: a maximum capable throughput of 40 Gbps. Thunderbolt is another transfer speed standard used in some USB-C cables—all Thunderbolt 3 and 4 cables are USB-C, but not all USB-C cables are Thunderbolt. So if Thunderbolt is what you're after, you'll need to make sure that's part of the cable you're buying.

https://www.howtogeek.com/53587/usb-explained-all-the-different-types-and-what-theyre-used-for/

Unfortunately the page has a lot of adds.
Use an adblocker or brave browser.

Bertus

Hi,

I read now that they are up to 80Gbps, that's amazing. Not sure if we could get this with some other kind of connector.

 

Hi,

I read now that they are up to 80Gbps, that's amazing. Not sure if we could get this with some other kind of connector.

How do we know? Does anyone have anything that can send or receive data at that speed? All I have is USB memory sticks and disc drives, and they are the limiting factor and they are slow!

 

Well, you are right about the form factor, they must have changed something since the very beginning, but there are different USB C connectors with respect to their ratings. Some are rated for less current than others, and probably for less voltage than others too.
The form factor is the same, except for the number of pins. Some will have lower pin count than others.

It's an issue if a C cable cannot handle the latest PD spec. I am not 100%, but IIRC all 4 vbus pins should be active in all C cables, so to have a cable sub-par to the PD 240w rating seems a bit counterproductive. If some of the vbus pins are missing I am not sure PD can recognize that.

This would also mean if you have both an Android phone and Apple phone you can use the same charger.

??
My Lightning-C cable plugs into all C ports, and my app-ill-phone. I use one multi-port C charger.

 

If overheating and catching fire were not problems, why would Bourns have invented these?
https://www.mouser.com/pdfdocs/bour...y6GJlPkvH5ALIbzqZlbDKj4MjqCTrsZVcc-hrupWg2892

 

How do we know? Does anyone have anything that can send or receive data at that speed? All I have is USB memory sticks and disc drives, and they are the limiting factor and they are slow!

Tbolt4 Tbolt5 are both on top of USB4.
Many USB4 sticks are "USB4-40", so 40gb transfer is doable over USB4.
Tbolt5 is a 80/120Gb spec, so what USB version supports 120Gb half-duplex only?

Why removeable things did not adopt Tbolt back in 2011 is very bewildering. Tbolt is superior protocol. Tbolt does it all, power/data/video/audio.

Although USB and Tbolt are implemented in C port, C port is not a requirement of USB or Tbolt. It's not a hard requirement because it makes no sense to limit the protocols to a specific physical port. Some day the D port will come out. If the port and connected devices can support "one cable", then things like "power over Tbolt" for connecting a laptop or PC to a monitor is all that is needed, which eliminates the extra PSU/cord needed to supply power to the monitor.

If innovation moved to support something like "one cable" for monitors (say up to 24" screen), then you can achieve reducing e-waste.

 

Tbolt4 Tbolt5 are both on top of USB4.
Many USB4 sticks are "USB4-40", so 40gb transfer is doable over USB4.
Tbolt5 is a 80/120Gb spec, so what USB version supports 120Gb half-duplex only?

Why removeable things did not adopt Tbolt back in 2011 is very bewildering. Tbolt is superior protocol. Tbolt does it all, power/data/video/audio.

Although USB and Tbolt are implemented in C port, C port is not a requirement of USB or Tbolt. It's not a hard requirement because it makes no sense to limit the protocols to a specific physical port. Some day the D port will come out. If the port and connected devices can support "one cable", then things like "power over Tbolt" for connecting a laptop or PC to a monitor is all that is needed, which eliminates the extra PSU/cord needed to supply power to the monitor.

If innovation moved to support something like "one cable" for monitors (say up to 24" screen), then you can achieve reducing e-waste.

I've followed this thread quite a bit but I'm confused on your position.

On one hand you say the current standards don't solve e-waste and are even making it worse.

On the other, you seem to expect a standard to come out which solves not only today's requirements, but also all that the future will bring.

Neither of these perspectives seem tenable to me but maybe I got it wrong. Do you have a response?

 

It's an issue if a C cable cannot handle the latest PD spec. I am not 100%, but IIRC all 4 vbus pins should be active in all C cables, so to have a cable sub-par to the PD 240w rating seems a bit counterproductive. If some of the vbus pins are missing I am not sure PD can recognize that.



??
My Lightning-C cable plugs into all C ports, and my app-ill-phone. I use one multi-port C charger.

You would not need anything with "lightning" in it anymore.

 

How do we know? Does anyone have anything that can send or receive data at that speed? All I have is USB memory sticks and disc drives, and they are the limiting factor and they are slow!

Not sure what you mean here. How do we know what?
It is not that important that we may or may not have anything that goes up to 80Gbps right now, because tomorrow we may have such a device. The world record right now is over 400Tbps which is a lot faster than 80Gbps.

I've been complaining about disk speeds for years now. It's not the speed of the device itself, it's the way it handles multiple transfers. If you have 1000 1k files it transfers much slower than if you have a single 1MByte file. That's really nasty when you have to store a lot of small files like I do.

 

Not sure what you mean here. How do we know what?
It is not that important that we may or may not have anything that goes up to 80Gbps right now, because tomorrow we may have such a device. The world record right now is over 400Tbps which is a lot faster than 80Gbps.

I've been complaining about disk speeds for years now. It's not the speed of the device itself, it's the way it handles multiple transfers. If you have 1000 1k files it transfers much slower than if you have a single 1MByte file. That's really nasty when you have to store a lot of small files like I do.

I mean that I don't know of device that could process data at that speed. I've mainly used USB for disc drives, and they rarely tax the transfer rate of the original USB. (Probably because, as you say, most operating systems are completely rubbish at putting a large number of small files on a disc.)

A colleague with a PA company has a USB device which replaces a stage snake (multiple microphone cables) and that isn't struggling for bandwidth either.

 

You would not need anything with "lightning" in it anymore.

How would it matter? Apple users usually stay with Apple products, "my" one C-Lightning cable will be used for "many many years", or about 6mo because most cables are crap and break.

 

I've followed this thread quite a bit but I'm confused on your position.

On one hand you say the current standards don't solve e-waste and are even making it worse.

On the other, you seem to expect a standard to come out which solves not only today's requirements, but also all that the future will bring.

Neither of these perspectives seem tenable to me but maybe I got it wrong. Do you have a response?

You missing the bigger picture.
Joules per bit. Maybe that's a good metric to look at in "efficiency"?

The physical C port solves no e-waste issue, even if you mandate it.

If all my stuff is A and micro, and now I buy a device that is C, then I need to buy more crud, another cable, a C cable, or the device came with a C cable, so that adds up to be more crud that will go into the trash eventually.

Tbolt / USB is not a "future" protocol, it's only being advanced, most likely by innovation in IC's that can go faster, are smaller, and use less power.

A future D port simply means something new will come along, leaving C in the dust, just as the C port from 2011 has made A and micro and most other USB related ports legacy, but this does not mean A and micro goes away, there's many many tons of A and micro crud still out there, probably will take 20+ years for all the A and micro stuff to vanish into the trash.

And then we have the issue of cable spec, cables will need to be certified , as example, "USB4-40" or "Tbolt v5" or just "5v 1A only". It becomes a mess when there's a zillion devices that all use one port (C port) but devices all require different types of cables, so now I need even more C cables.

I need to check, but it was not clear to me if Tbolt v5 certified cable supports the latest PD power spec of 250w (up to 50v 5A). And then you'll have 20 different cables for the 20 different version of "PD" spec (exaggerated # "20"), but they'll all be C cables.

And yes, we should expect backward compatibility in cables, Tbolt v5 supports all previous Tbolt, USB4 supports all previous USB, but "should" is the important word there. If Tbolt v6 goes to a "USB D" port, then backwards compatability is lost. I can't see protocols being limited by a physical port. If Tbolt v6 needs something better than C port, then a new port shall come.

 

I've been complaining about disk speeds for years now. It's not the speed of the device itself, it's the way it handles multiple transfers. If you have 1000 1k files it transfers much slower than if you have a single 1MByte file. That's really nasty when you have to store a lot of small files like I do.

OS matters.

Devices at the storage level are quite fast. SSD's are 3000MB/s, Byte, so x8 for bit, thus 24,000Mb/s or 24Gb/s, still slower than USB4-40 and much slower than Tbolt.

But, some SSD's from Crucial (PCIe gen5) are getting 14,500MB/s, or 116Gb/s, which is on-par with Tbolt v5 half-duplex only 120Gb/s.

Technology in many areas play leap-frog on each other.

 

How would it matter? Apple users usually stay with Apple products, "my" one C-Lightning cable will be used for "many many years", or about 6mo because most cables are crap and break.

Ok good luck with it.

Maybe you could start to complain about the plastic used in all this stuff including the cables. Plastic is in everything now. They say it's even in the blood of animals around the world. They are calling it "microplastics".

Or maybe we should start to stop doing everything that way we don't waste anything

 

I mean that I don't know of device that could process data at that speed. I've mainly used USB for disc drives, and they rarely tax the transfer rate of the original USB. (Probably because, as you say, most operating systems are completely rubbish at putting a large number of small files on a disc.)

A colleague with a PA company has a USB device which replaces a stage snake (multiple microphone cables) and that isn't struggling for bandwidth either.

Hi,

Well the issues and applications are not that obvious sometimes.
For example, if we had one USB drive that needs 10Gbps that would only use 1/8 of the bandwidth of an 80Gbps interface, or just 1/4 of the bandwidth of a 40Gbps interface. But if we fan out to 2 USB drives, that 80Gbps is used at 1/4 of it's BW, and the 40Gbps is now sued at 1/2 it's total BW. Fan out to 4 USB drives and 80Gbps is now used at 1/2 it's total BW, and the 40Gbps tops out a the full BW.
That's with drives that need 10Gbps, but the newer M2 drives need more than that, so maybe we can get 2 USB drives to work on the 40Gbps interface maybe not. Those newer drives are really fast.
So the fanout comes into play here also it's not always about one device plugged into one connector. Another use is with multiply displays. Four 8k displays through one USB C connector.
Then there are the USB hubs. One USB C connector fanout to 8 USB ports.

There's also the settings on the drives. "Enable write caching for this device", which improves the 'apparent' transfer speed. The effectiveness would depend on how much the drive can store electronically before actually storing it on the disk.

 

OS matters.

Devices at the storage level are quite fast. SSD's are 3000MB/s, Byte, so x8 for bit, thus 24,000Mb/s or 24Gb/s, still slower than USB4-40 and much slower than Tbolt.

But, some SSD's from Crucial (PCIe gen5) are getting 14,500MB/s, or 116Gb/s, which is on-par with Tbolt v5 half-duplex only 120Gb/s.

Technology in many areas play leap-frog on each other.

It does not seem to matter what the speed of the drive is, it's still slower with the larger number of smaller files. Could it be the overhead too. If you go from a drive that is 100MB/s to one that does 200MB/s you get faster speeds for everything, but the 1000 1k files still take longer than the single 1MB file. It's even worse with 10000 files.
Granted, things have gotten better of the past 5 years or so since we are getting away from the SATA interface.

OS does not matter because you are not going to switch OS's just to get faster drive speed.

 

, but the 1000 1k files still take longer than the single 1MB file.

OS does not matter because you are not going to switch OS's just to get faster drive speed

OS does matter, you have a choice as to what device you may buy. If one runs a small linux kernel and the other is a windoze kernel, I would buy the one that had better specs, those specs are likely better because of the OS that is used in the device, as example.


Recall that 1000 x 1k files on disk does not equal 1 x 1MB file on disk.
Recall that every one file has a ton of overhead in the OS.
Even if you match file size to match allocation exactly, OS still has lots of other tracking to do (in OS files) with each write of a new or existing file.

It also matter how you conduct I/O. As example, if the 1000 1k files are all contiguous from device block 10 to 40,556, I can essentially do one block level copy using something like dd utility, copy (read & write) blocks 10 to 40,556 in 4MB chunks, that's much faster than asking OS to copy each file individually from point A to point B.

That all has to do with filesystem types, allocation size, and, OS kernel. File size is not allocated size.
I can tune a Linux system to have very very good I/O, but I had compile OS, pick better filesystem, choose allocation just right, tweak available parameters, etc. From what I see, not much of anything these days is highly tuned for performance out-of-the-box. Not everything is as robust as say Linux, hence device I/O can/will be limited.

It is true, we only realize that it took 4min on stopwatch to tansfer the file, even though the data made it across the wire in just 3.8min.

I think the context of the speed matters, data file transfer that has software OS/cpu in the middle of both ends, vs video/audio data that is transferred and processed by hardware in almost realtime (video monitor as example).

But in grand scheme of it, the protocols used should never be bound to a physical port, because at some point an advancement to the protocol may need an extra 2 pins, as example.

 

OS does matter, you have a choice as to what device you may buy. If one runs a small linux kernel and the other is a windoze kernel, I would buy the one that had better specs, those specs are likely better because of the OS that is used in the device, as example.


Recall that 1000 x 1k files on disk does not equal 1 x 1MB file on disk.
Recall that every one file has a ton of overhead in the OS.
Even if you match file size to match allocation exactly, OS still has lots of other tracking to do (in OS files) with each write of a new or existing file.

It also matter how you conduct I/O. As example, if the 1000 1k files are all contiguous from device block 10 to 40,556, I can essentially do one block level copy using something like dd utility, copy (read & write) blocks 10 to 40,556 in 4MB chunks, that's much faster than asking OS to copy each file individually from point A to point B.

That all has to do with filesystem types, allocation size, and, OS kernel. File size is not allocated size.
I can tune a Linux system to have very very good I/O, but I had compile OS, pick better filesystem, choose allocation just right, tweak available parameters, etc. From what I see, not much of anything these days is highly tuned for performance out-of-the-box. Not everything is as robust as say Linux, hence device I/O can/will be limited.

It is true, we only realize that it took 4min on stopwatch to tansfer the file, even though the data made it across the wire in just 3.8min.

I think the context of the speed matters, data file transfer that has software OS/cpu in the middle of both ends, vs video/audio data that is transferred and processed by hardware in almost realtime (video monitor as example).

But in grand scheme of it, the protocols used should never be bound to a physical port, because at some point an advancement to the protocol may need an extra 2 pins, as example.

I don't think you are thinking in practical terms.

You really think I am going to go out and buy a new and different OS system to get faster file transfers? How much faster could it be.
The biggest change came in with the advent of SATA from EIDE, which are two of the interfaces newer and older.

Then you are talking about the file system, and there's no file system that I know of that would help the small file transfer speed, and it's not that dependent on file 'overhead' such as allocation unit size.
For example, for a certain allocation unit size we may have a file that is 1000 bytes actually taking up 1200 bytes, yet the transfer speed could be 10 times longer than with a larger file that has all the bytes in one file. Current allocation size is around 4k bytes, but when I used the example of 1k file sizes that was just to keep the math simple. I am really talking about 100k to maybe 300k file sizes as compared to 1Gbyte file size. If you figure that 1GByte of 100k files would take 10000 files, we are talking a HUGE difference in transfer speed, from a few seconds for the 1G file to maybe 2 minutes for the 10000 files around 100k each. You can try this yourself just by creating 10000 files in a directory, then copy to some disk. Then do a 1G file and copy that. See what the difference is.

I will probably eventually turn to all M2 NVMe SSD's in the future, using the external NVMe enclosures. They do faster than SATA.

I am not sure it is worth talking about this too much though because we can only change so much with our own systems and we are sort of stuck with whatever technology we get thrown at us.

I had considered making a new file system also, but then the bulk of the time is spent in the CPU with packing and unpacking files. Makes everything more difficult and the end result is not that great anyway.

 

You really think I am going to go out and buy a new and different OS system to get faster file transfers? How much faster could it be.

[...]

Then you are talking about the file system, and there's no file system that I know of that would help the small file transfer speed, and it's not that dependent on file 'overhead' such as allocation unit size.

[...]

I am not sure it is worth talking about this too much though because we can only change so much with our own systems and we are sort of stuck with whatever technology we get thrown at us.

File systems that support block suballocation and tail packing are considerably faster when handling many small files. It is possible to use a variety of file systems with FUSE (Filesystem in USErspace) even with Windows. FUSE has a long list of filesystems written for it.

In any case, like all things, filesystems can be optimized for particular performance goals at the expense of others. Depending on the actual use case, there are options that will perform better than something intended to provide general performance.