Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. The Lounge
  4. Which device is "faster "?

Which device is "faster "?

Scheduled Pinned Locked Moved Unsolved The Lounge
19 Posts 8 Posters 3.5k Views 5 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Chris KawaC Offline
    Chris KawaC Offline
    Chris Kawa
    Lifetime Qt Champion
    wrote on last edited by Chris Kawa
    #4

    There's a couple of factors here and the physical type of the storage device is only one of them.

    As mentioned above the second thing is the USB standard used. there are multiple of them at this point and they have their theoretical peak listed here. Theoretical is one but USB dongles vary wildly in quality and they rarely achieve those peak speeds.

    The third thing is the standard supported by your motherboard. USB is backwards compatible and switches to the lowest mode supported by all devices connected to the same port so even if your dongle is high speed it might be limited by the motherboard. If you don't know which port you have look at its color - black is USB 2.0, blue is 3.1 Gen 1 and teal is 3.1 Gen 2 (the fastest).

    Fourth thing, which is often omitted but really important, is your computer case (in case of desktops). It's very common in lower end cases to have a poor quality connector forwarded to the front of your case where you usually stick your dongles, so even if your dongle is fast and your motherboard can handle it, you might be limited by the cable in the case. This obviously applies only to desktops as laptops usually have their ports sticking directly out of the motherboard.

    That being said there are blazingly fast dongles out there, but they are not cheap and you need to keep an eye on all the above params.

    EDIT: Oh, and one more thing when installing an OS from a dongle. Even if all above params are fast your BIOS might limit the speed of the device to the lowest standard when booting from it to maximize compatibility.

    JonBJ 1 Reply Last reply
    6
    • Chris KawaC Chris Kawa

      There's a couple of factors here and the physical type of the storage device is only one of them.

      As mentioned above the second thing is the USB standard used. there are multiple of them at this point and they have their theoretical peak listed here. Theoretical is one but USB dongles vary wildly in quality and they rarely achieve those peak speeds.

      The third thing is the standard supported by your motherboard. USB is backwards compatible and switches to the lowest mode supported by all devices connected to the same port so even if your dongle is high speed it might be limited by the motherboard. If you don't know which port you have look at its color - black is USB 2.0, blue is 3.1 Gen 1 and teal is 3.1 Gen 2 (the fastest).

      Fourth thing, which is often omitted but really important, is your computer case (in case of desktops). It's very common in lower end cases to have a poor quality connector forwarded to the front of your case where you usually stick your dongles, so even if your dongle is fast and your motherboard can handle it, you might be limited by the cable in the case. This obviously applies only to desktops as laptops usually have their ports sticking directly out of the motherboard.

      That being said there are blazingly fast dongles out there, but they are not cheap and you need to keep an eye on all the above params.

      EDIT: Oh, and one more thing when installing an OS from a dongle. Even if all above params are fast your BIOS might limit the speed of the device to the lowest standard when booting from it to maximize compatibility.

      JonBJ Offline
      JonBJ Offline
      JonB
      wrote on last edited by JonB
      #5

      @Chris-Kawa
      This makes interesting reading for me, with my slow-speed USB stick (I guess, it was probably cheap!) attached to my old desktop :)

      I looked at those peak speeds you referenced, for my black (USB 2) desktop port. But tell me one thing: is write speed the same as read speed? (I think) I find writing to USB dongle massively slower than reading from it??

      KroMignonK 1 Reply Last reply
      0
      • JonBJ JonB

        @Chris-Kawa
        This makes interesting reading for me, with my slow-speed USB stick (I guess, it was probably cheap!) attached to my old desktop :)

        I looked at those peak speeds you referenced, for my black (USB 2) desktop port. But tell me one thing: is write speed the same as read speed? (I think) I find writing to USB dongle massively slower than reading from it??

        KroMignonK Offline
        KroMignonK Offline
        KroMignon
        wrote on last edited by
        #6

        @JonB said in Which device is "faster "?:

        is write speed the same as read speed

        Short answer NO

        USB dongle storage speed depends on many factors:

        • USB Version (1.0, 1.1, 2.0, 3.0, etc.) only specifies the maximum theoretical data transfer speed on bus
        • how many devices connected on bus
        • The storage hardware, in other words the FLASH memory technologie: this will specify the read/write speed (cf. https://en.wikipedia.org/wiki/USB_flash_drive or https://en.wikipedia.org/wiki/Flash_memory)
        • used file system

        It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

        JonBJ 1 Reply Last reply
        0
        • KroMignonK KroMignon

          @JonB said in Which device is "faster "?:

          is write speed the same as read speed

          Short answer NO

          USB dongle storage speed depends on many factors:

          • USB Version (1.0, 1.1, 2.0, 3.0, etc.) only specifies the maximum theoretical data transfer speed on bus
          • how many devices connected on bus
          • The storage hardware, in other words the FLASH memory technologie: this will specify the read/write speed (cf. https://en.wikipedia.org/wiki/USB_flash_drive or https://en.wikipedia.org/wiki/Flash_memory)
          • used file system
          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by JonB
          #7

          @KroMignon said in Which device is "faster "?:

          The storage hardware, in other words the FLASH memory technologie: this will specify the read/write speed

          Yes, this is what I was thinking of, my actual physical dongle's speed, not the bus speed. I see your link states:

          USB flash drives usually specify their read and write speeds in megabytes per second (MB/s); read speed is usually faster.

          [My bold.] I use one physical stick (32GB, several years old), and I have no idea what it is or what its ratings are! All I know is: it's damn slow at backing up 0.5GB tar file at the end of my working day before I can power off the Linux box. From start to end of flushing to stick (which obviously comes after tar command has completed, the drive is cached) it's 90 seconds I have to sit there watching its light flash.... The same tar to /tmp (SSD) takes 45 seconds by comparison, half the time. Is that about right?? :) (When I look at this it doesn't seem so bad at all for stick comparatively; maybe it's because I want to knock off and leave that the backup to stick feels so long!!)

          KroMignonK 1 Reply Last reply
          0
          • JonBJ JonB

            @KroMignon said in Which device is "faster "?:

            The storage hardware, in other words the FLASH memory technologie: this will specify the read/write speed

            Yes, this is what I was thinking of, my actual physical dongle's speed, not the bus speed. I see your link states:

            USB flash drives usually specify their read and write speeds in megabytes per second (MB/s); read speed is usually faster.

            [My bold.] I use one physical stick (32GB, several years old), and I have no idea what it is or what its ratings are! All I know is: it's damn slow at backing up 0.5GB tar file at the end of my working day before I can power off the Linux box. From start to end of flushing to stick (which obviously comes after tar command has completed, the drive is cached) it's 90 seconds I have to sit there watching its light flash.... The same tar to /tmp (SSD) takes 45 seconds by comparison, half the time. Is that about right?? :) (When I look at this it doesn't seem so bad at all for stick comparatively; maybe it's because I want to knock off and leave that the backup to stick feels so long!!)

            KroMignonK Offline
            KroMignonK Offline
            KroMignon
            wrote on last edited by
            #8

            @JonB said in Which device is "faster "?:

            I have to sit there watching its light flash...

            There are many reason why it is slow:

            • the FLASH is "old", and there are many bad blocks and the wear leverage algorithm has many work to do (USB-strick internal firmware)
            • the used file system is not adapted: many USB dongle are design to be used with FAT/FAT32 file system
            • on host, the file system caches are not "optimal"

            It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

            JonBJ 1 Reply Last reply
            0
            • KroMignonK KroMignon

              @JonB said in Which device is "faster "?:

              I have to sit there watching its light flash...

              There are many reason why it is slow:

              • the FLASH is "old", and there are many bad blocks and the wear leverage algorithm has many work to do (USB-strick internal firmware)
              • the used file system is not adapted: many USB dongle are design to be used with FAT/FAT32 file system
              • on host, the file system caches are not "optimal"
              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by JonB
              #9

              @KroMignon
              I have just typed in some timings above. In a word, if the stick write is twice as long as the "disk" (I actually have SSD) write is that actually not a bad speed at all?

              KroMignonK 1 Reply Last reply
              0
              • JonBJ JonB

                @KroMignon
                I have just typed in some timings above. In a word, if the stick write is twice as long as the "disk" (I actually have SSD) write is that actually not a bad speed at all?

                KroMignonK Offline
                KroMignonK Offline
                KroMignon
                wrote on last edited by KroMignon
                #10

                @JonB said in Which device is "faster "?:

                is that actually not a bad speed at all?

                You are trying to compare two different technologies: you SSD which use (m)SATA (up to 600MB/sec), PCI-e (up to 32GB/sec) or M.2 (up to 4GB/sec) interface and USB which I suppose is an USB2.0 full speed one (480Mbit/s ==> 60MB/sec)

                And the used FLASH technology, to do the storage, is at least not the same.

                You are using Linux, but what is the used file system for your USB storage?
                How did you mount the USB storage: do you use "sync" in mount option, which is a performance killer for USB devices?

                It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

                kshegunovK JonBJ 2 Replies Last reply
                0
                • KroMignonK KroMignon

                  @JonB said in Which device is "faster "?:

                  is that actually not a bad speed at all?

                  You are trying to compare two different technologies: you SSD which use (m)SATA (up to 600MB/sec), PCI-e (up to 32GB/sec) or M.2 (up to 4GB/sec) interface and USB which I suppose is an USB2.0 full speed one (480Mbit/s ==> 60MB/sec)

                  And the used FLASH technology, to do the storage, is at least not the same.

                  You are using Linux, but what is the used file system for your USB storage?
                  How did you mount the USB storage: do you use "sync" in mount option, which is a performance killer for USB devices?

                  kshegunovK Offline
                  kshegunovK Offline
                  kshegunov
                  Moderators
                  wrote on last edited by
                  #11

                  M.2 is a four lane PCI-E, which is the whole point of having it in the first place; you want the SSD to be on the bus.

                  Read and abide by the Qt Code of Conduct

                  1 Reply Last reply
                  1
                  • KroMignonK KroMignon

                    @JonB said in Which device is "faster "?:

                    is that actually not a bad speed at all?

                    You are trying to compare two different technologies: you SSD which use (m)SATA (up to 600MB/sec), PCI-e (up to 32GB/sec) or M.2 (up to 4GB/sec) interface and USB which I suppose is an USB2.0 full speed one (480Mbit/s ==> 60MB/sec)

                    And the used FLASH technology, to do the storage, is at least not the same.

                    You are using Linux, but what is the used file system for your USB storage?
                    How did you mount the USB storage: do you use "sync" in mount option, which is a performance killer for USB devices?

                    JonBJ Offline
                    JonBJ Offline
                    JonB
                    wrote on last edited by JonB
                    #12

                    @KroMignon
                    You (I, actually!) have opened a whole can of worms here :) I realize I have hijacked this thread, and should probably take it to Lounge if I want to pursue.

                    Since you've asked, I'll just answer briefly. It's a Linux VM guest (VirtualBox) 64-bit on 64-bit Windows 7 host. Filing system is fuse from Linux point of view, it's NTFS formatted from Windows so that I can access stick from Windows too if I want to. (From what you say about FAT32, maybe this is not optimal?) I don't think the Linux mounts it sync, because as I say the red light continues to flash after that tar has completed if I try to shut down the Linux or if I wait a while after writing to it, as I would expect cached-non-sync to do.

                    mount: /dev/sdb1 on /media/jon/HOME_STICK type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

                    I realize that goodness knows what's going on with VB drivers through Linux to Windows, the non-native Linux filing system etc.. What I should do is start by doing all my timings back in Windows before comparing against Linux.....

                    KroMignonK Kent-DorfmanK 2 Replies Last reply
                    0
                    • JonBJ JonB

                      @KroMignon
                      You (I, actually!) have opened a whole can of worms here :) I realize I have hijacked this thread, and should probably take it to Lounge if I want to pursue.

                      Since you've asked, I'll just answer briefly. It's a Linux VM guest (VirtualBox) 64-bit on 64-bit Windows 7 host. Filing system is fuse from Linux point of view, it's NTFS formatted from Windows so that I can access stick from Windows too if I want to. (From what you say about FAT32, maybe this is not optimal?) I don't think the Linux mounts it sync, because as I say the red light continues to flash after that tar has completed if I try to shut down the Linux or if I wait a while after writing to it, as I would expect cached-non-sync to do.

                      mount: /dev/sdb1 on /media/jon/HOME_STICK type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

                      I realize that goodness knows what's going on with VB drivers through Linux to Windows, the non-native Linux filing system etc.. What I should do is start by doing all my timings back in Windows before comparing against Linux.....

                      KroMignonK Offline
                      KroMignonK Offline
                      KroMignon
                      wrote on last edited by KroMignon
                      #13

                      @JonB

                      Wish you good luck to optimize your backup process!
                      There are many software layers which are involved ;)

                      It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

                      JonBJ 1 Reply Last reply
                      1
                      • KroMignonK KroMignon

                        @JonB

                        Wish you good luck to optimize your backup process!
                        There are many software layers which are involved ;)

                        JonBJ Offline
                        JonBJ Offline
                        JonB
                        wrote on last edited by JonB
                        #14

                        @KroMignon
                        You are absolutely right. But speed is probably only a minor problem. About half the time the Linux guest does not get the USB at all from the Windows host, though the host has passed it on and cannot access it, but can't get it from Linux either. And the only way is to reboot host (not just guest) and try again till it does. Yet no such problem to stick from Windows when no Linux guest fired up. And yes I've asked at VirtualBox and they don't know what to diagnose is going on. So I have plenty of headaches :) Thanks for your comments.

                        1 Reply Last reply
                        0
                        • A Offline
                          A Offline
                          Anonymous_Banned275
                          wrote on last edited by
                          #15

                          Wow
                          what an interesting response to silly, out of boredom , post.
                          Not a single "RTFM"!
                          Maybe this is the best sub-forum to post technical stuff disguised as "beer talk"...

                          1 Reply Last reply
                          0
                          • JonBJ JonB

                            @KroMignon
                            You (I, actually!) have opened a whole can of worms here :) I realize I have hijacked this thread, and should probably take it to Lounge if I want to pursue.

                            Since you've asked, I'll just answer briefly. It's a Linux VM guest (VirtualBox) 64-bit on 64-bit Windows 7 host. Filing system is fuse from Linux point of view, it's NTFS formatted from Windows so that I can access stick from Windows too if I want to. (From what you say about FAT32, maybe this is not optimal?) I don't think the Linux mounts it sync, because as I say the red light continues to flash after that tar has completed if I try to shut down the Linux or if I wait a while after writing to it, as I would expect cached-non-sync to do.

                            mount: /dev/sdb1 on /media/jon/HOME_STICK type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

                            I realize that goodness knows what's going on with VB drivers through Linux to Windows, the non-native Linux filing system etc.. What I should do is start by doing all my timings back in Windows before comparing against Linux.....

                            Kent-DorfmanK Offline
                            Kent-DorfmanK Offline
                            Kent-Dorfman
                            wrote on last edited by
                            #16

                            @JonB Funny it wasn't mentioned but a single huge throttle to your throughput I will sum up in one word FUSE - filesystem in user space. All that IO is being managed in userspace but still requires copies to/from kernel land to do the low level disk IO. As for flash technologies and their features/limitations...I'm not even gonna get started. LOL

                            The dystopian literature that served as a warning in my youth has become an instruction manual in my elder years.

                            JonBJ 1 Reply Last reply
                            0
                            • Kent-DorfmanK Kent-Dorfman

                              @JonB Funny it wasn't mentioned but a single huge throttle to your throughput I will sum up in one word FUSE - filesystem in user space. All that IO is being managed in userspace but still requires copies to/from kernel land to do the low level disk IO. As for flash technologies and their features/limitations...I'm not even gonna get started. LOL

                              JonBJ Offline
                              JonBJ Offline
                              JonB
                              wrote on last edited by JonB
                              #17

                              @Kent-Dorfman
                              Interesting, but quite beyond me :) "Hardware"/"driver" issues like this is not my area!

                              Here's my take, as a layman. All I am copying is a large (0.5GB) single file --- not lots of small ones, so we' may be talking about block allocation but not many directory entries allocation. There is a physical stick in the port. It is "slow". I don't really know whether that is slow at the USB port, or (more likely) slow in the physical stick. "Filesystem in user space", copying to/from the kernel, anything else to do with memory/CPU access == fast, comparatively. You could probably put The Treacle File System on that stick and it would make little difference. The only real slowness comes when something tries to physically push a byte out onto that stick.

                              Is that not right? I am interested in these things, but know nothing :)

                              KroMignonK 1 Reply Last reply
                              0
                              • JonBJ JonB

                                @Kent-Dorfman
                                Interesting, but quite beyond me :) "Hardware"/"driver" issues like this is not my area!

                                Here's my take, as a layman. All I am copying is a large (0.5GB) single file --- not lots of small ones, so we' may be talking about block allocation but not many directory entries allocation. There is a physical stick in the port. It is "slow". I don't really know whether that is slow at the USB port, or (more likely) slow in the physical stick. "Filesystem in user space", copying to/from the kernel, anything else to do with memory/CPU access == fast, comparatively. You could probably put The Treacle File System on that stick and it would make little difference. The only real slowness comes when something tries to physically push a byte out onto that stick.

                                Is that not right? I am interested in these things, but know nothing :)

                                KroMignonK Offline
                                KroMignonK Offline
                                KroMignon
                                wrote on last edited by KroMignon
                                #18

                                @JonB said in Which device is "faster "?:

                                The only real slowness comes when something tries to physically push a byte out onto that stick.
                                Is that not right? I am interested in these things, but know nothing :)

                                To fulfill this, my (last) 2 cts.
                                I am also had speed limitations on file transfer between VirtalMachine Guest (Linux/Ubuntu) <=> Host (Windows 7/10).
                                One trick what helps me was to use SAMBA, which transfer rates was much more better as Shared Directory (with VirtualBox).

                                But this implies 2 transfers, on from Guest to Host and then vom Host to USB-Stick, it is not so smart but quicker ;)

                                It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

                                1 Reply Last reply
                                1
                                • N Offline
                                  N Offline
                                  ND Diploma
                                  Banned
                                  wrote on last edited by
                                  #19
                                  This post is deleted!
                                  1 Reply Last reply
                                  -2

                                  • Login

                                  • Login or register to search.
                                  • First post
                                    Last post
                                  0
                                  • Categories
                                  • Recent
                                  • Tags
                                  • Popular
                                  • Users
                                  • Groups
                                  • Search
                                  • Get Qt Extensions
                                  • Unsolved