53 replies to this topic

[MedEvil]

The structure of the installer is like this.
Install.exe | Autorun.exe | TurboFlash_Install.exe | - Files - | TurboFlash_Install.exe | Autorun.exe | Install.exe

It's basicly 3 installers stached in eachother.

The - Files - consist of 1 .exe, 2 32Bit drivers and 2 64Bit drivers. Supposedly there should also be 2 .inf, but i can't find them.

Does anyone know, how to tell a 32Bit driver from a 64Bit one?

[Wonko the Sane]

Think outside the box

For the record, what you suggest is usually called NOT "thinking out of the box", but rather "go mainstream" (and "forking from some more money" ).



Next time you find someone with a flat tire, stop by and tell him to buy an helicopter, cars are soooo ooold fashion , I am pretty sure he/she will appreciate your suggestion.


Wonko

[MedEvil]

Because of the USB3 post from BLUEMONKEY_STU, i did some calculations to check for sense and nonsense of USB3 for our purposes.

A NaughtyPE.wim is 120MB in size. How long would loading the image take with different speeds?

USB 1.1
120MB : 1,2MB/s = 100sec =1min 40sec

USB 2.0
120MB : 5MB/s = 24,0sec
120MB : 10MB/s = 12,0sec
120MB : 15MB/s = 8,0sec
120MB : 20MB/s = 6,0sec
120MB : 25MB/s = 4,8sec
120MB : 30MB/s = 4,0sec
120MB : 40MB/s = 3,0sec

USB 3.0
120MB : 50MB/s = 2,4sec
120MB : 100MB/s = 1,2sec
120MB : 150MB/s = 0,8sec


Given that the rest of the boot process takes (hardware dependant) between 20 and 40 seconds, i would say, that any speed above 10MB/s is good. Everything over 20MB/s not noticable and not worth to spend an extra dime.

High speeds above a certain point, just makes sense, if the file is big enough.

[Wonko the Sane]

Does anyone know, how to tell a 32Bit driver from a 64Bit one?

Is this what you are asking in a general way, or are you asking how to check specifically among the specific files you extracted with 7-zip or whatever, which ones are 32-bit and which ones are 64?

If the latter, try opening them in a hex-editor and search for "amd64" or use bintext on them:
http://www.foundston...esc/bintext.htm


Wonko

[MedEvil]

Is this what you are asking in a general way, or are you asking how to check specifically among the specific files you extracted with 7-zip or whatever, which ones are 32-bit and which ones are 64?

Thanks, found amd64 in one set. Expected as much, as those drivers are the ones, which are a bit bigger than the others.
But always nice to be sure.

[Wonko the Sane]

But always nice to be sure.

Naaah, it takes most of the fun out of it.

A small puzzle for you :
Which English word is most often associated with "Turbo", begins with "b" and rhymes with "Induced"? (choose one):

• boat
• bloat
• boot
• boost
• blest
• breast

... try connecting the dots .....
http://www.lacie.com...ivers/index.htm


Wonko

[MedEvil]

I followed the yellow brick road and have to say: "Nice find, you sly dog!"

Good Finder. Good Finder. Yes, this is a good Finder!

The drivers seem to be older versions of the ones on Mushkins site and the control program is definitly different. There is no extra button to unmount the drive.
Eighter Lacie/FNET trust this job to the Windows tool or it wasn't yet necessary with this version.

Anyway, i have now the needed registry entries and could see, that there are no inf extracted, so i can stop looking for them.


Next step: Figuring out, how the driver(pair) does, what it does.

[Wonko the Sane]

Next step: Figuring out, how the driver(pair) does, what it does.

And IF/HOW MUCH it does.

Check the FAQ's on the LaCie manual.


Wonko

[MedEvil]

And IF/HOW MUCH it does.

Since i neighter own a Lacie nor a Mushkin compatible 'drive', i would need, for that, to 'break' the software, for purely educational purposes.

[Sha0]

The software is (obviously ) from China:

...
Copyright © 2006-2009, FNet Co., Ltd. All rights reserved.
#40, Yong-Le 5th St., Chia-yi city, Taiwan 600

?!

MedEvil: You should also be able to use Dependency Walker (Depends.exe) to check the architecture for a driver.
Note the CPU column (and other useful things).

If anyone gets this driver installed, you could search the Registry for its filename to determine what service it is, then you could search for that service name to see if it's an UpperFilters or LowerFilters filter driver, which would be my guess. If it's not, then it might just be non-kernel code.

I am personally suspicious of anything that claims to boost performance. Businesses can obviously really know something or can be up to no good with slimy trickery. Slimy trickery might include pre-caching during idle cycles for reads. For the write speed increase, you could do the following test:

• Write all zeroes to the USB storage (Olof's Random and Zero driver)
• Get your stop-watch ready to go
• Use a Windows counterpart of my fill.com (which is DOS) to write an all-ones buffer to every "sector" of the USB storage
• Yank the USB out at some point while simultaneously stopping your stop-watch
• Wait a minute, then re-insert the USB storage and examine how many "sectors" were filled with all ones

The fact that one is supposed to Safely remove hardware for USB storage means that someone slimy could delay It is now safe to remove... until some delayed writing had its chance to complete. For example, I could delay all writing and save it all to RAM. Transfers would appear instantaneous. Then when you'd go to Safely remove..., I could take 15 minutes before telling you it's safe to remove, which you, the user, might just chalk up to a file-in-use error or some other quirk.

[MedEvil]

Well the Buffalo driver is really a single driver setup, with an per device installer.

The FNET one works different. It consists of 2 drivers and a controlling exe.
One of the drivers starts at bootup, while the second gets started by the controlling exe, which allows to enable and disable the driver for a specific device on the fly.

Buffalo
- BFTURBOH.SYS - UpperFilter

FNET
- FNETURPX.SYS - ?
- FNETTBOH.SYS - ?
No info about those two. Eighter because no device was ever associated with them or because the Buffalo driver overwrote the setting.

[MedEvil]

PS: About the slimy part.

Wonko and i already talked about possible ways the driver could work.
Though some ideas were pretty clever, imo, non fitted with reports found on the net about the drivers performance.

Namely, that it only works good for large files, while doing less and less, the smaller the file size gets. (For USB-Sticks)
Any cache based approach, should do the exact opposite and boost the speed for lots of small files the most.

[cdob]

possible ways the driver could work.

Crystal ball:

There are different USB transport modes.

Mass Storage Class use Bulk-Only Transport.
http://www.usb.org/d...massbulk_10.pdf
Windows default drivers use this mode.

http://zone.ni.com/d...a/tut/p/id/3705

USB protocol permits four different types of transfers -
control, bulk, isochronous, and interrupt (polled).

http://focus.ti.com/...6a/spru596a.pdf
http://www.cypress.com/?docID=4401

I guess:
TurboFlash use a different transfer mode.
There is a longer aceess time and faster continuous transfer rate.
The Midnight Series controller support bulk transport and another transport mode.
Windows default drivers use bulk transport.
The TurboFlash driver enable the second transport mode.
I've no idea about further details.

[Wonko the Sane]

I guess:
TurboFlash use a different transfer mode.
There is a longer aceess time and faster continuous transfer rate.
The Midnight Series controller support bulk transport and another transport mode.
Windows default drivers use bulk transport.
The TurboFlash driver enable the second transport mode.
I've no idea about further details.

It does sound likely.

Maybe it's a combination of a cache and of a faster, chunkier transfer mode.


Wonko

[MedEvil]

cdob, do you have any knowledge, about how to test for support of the different transport modes by the drive controller?

[Wonko the Sane]

It makes even more sense if it comes to a price:
http://www.freebsd.o...ok/usb-dev.html

If the transfer mode is the "isochronous" one, it may be faster but without a "built-in" guarantee of "delivery", not the best to backup a file...
http://www.syncroness.com/elec_usb.htm

Protocol Questions
Which data transfer modes are required? There are four transfer modes: Control, Bulk, Interrupt and Isochronous.

• All devices use the Control transfer and may use one or more of the others.
• Bulk transfers are non-periodic, large burst communications typically used for a transfer that can use any available bandwidth and can also be delayed until bandwidth is available. Disks, printers and scanners are examples.
• Interrupt transfer characteristics are small data, non-periodic, low-frequency, and bounded-latency. They are typically used to handle service needs. Mice and keyboards are examples
• Isochronous transfers are used when working with isochronous data. They provide periodic, continuous communication between host and device. Streaming audio and video are examples.

http://www.jungo.com...sfer_types.html

http://findarticles....3/ai_n29098585/

So, it is possible that they found a way to "verify" data through "isochronous".


But it is also possible that somehow the driver makes bigger packets:
http://en.wikipedia....eds_in_practice

http://www.usbmadesi...co.uk/ums_7.htm


Wonko

[MedEvil]

Found something new to the TurboUSB.
http://www.tomshardw...rbo,3215-3.html

This page describes that USB TurboMode could be enabled by simply setting a registry entry and it is shown, to give 25%-33% speed improvement for serial transfers. Worsening random access at the same time.

I just ran a bunch of tests with 2 USB-Sticks and a USB-HDD and couldn't find any difference in the performance.

Would be nice, if someone else could test it too.

[Wonko the Sane]

This page describes that USB TurboMode could be enabled by simply setting a registry entry and it is shown, to give 25%-33% speed improvement for serial transfers. Worsening random access at the same time.

I just ran a bunch of tests with 2 USB-Sticks and a USB-HDD and couldn't find any difference in the performance.

Nice find but on which OS?

Does it apply to USB 2.0 or only to USB 3.0?

 

A page found by searching for "HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Control\usbstor\054C00C1"

http://www.blogsolut...indows-7/17866/

 

Another page (Italian version of the article you found, but google translate is not that bad), check the post by repne scasb:

http://local.tomshw....?pag_commenti=1

http://www.tomshw.it...?pag_commenti=3

 

Wonko

[MedEvil]

The registry key applies to all USB versions. As does the described way this will affect performance.
It is a tweak to the performance of the protocol, tuning it in favor of serial transfers over random access.

Will check the links later.

[MedEvil]

I hate those data collectors!
Now i first have to find a service for disposable emails.

Wasn't there once this famous song in the US: "...land of the free, home of the brave"
Guess M$ headquaters have been moved behind the iron curtain.

[MedEvil]

I hate those morons that M$ employs these days!!!

First one needs to jump through hoops to get a hotfix. A freaking HOTFIX!
Then they tell you 3 times, that this hotfix isn't properly tested and should not be used by a "computer idiot". Which doesn't stop them from delivering the hotfix in a way, which is unusable to any admin, as this hot fix needs to be executed on every machine.

And if one chooses to install the hotfix, one can see a window reading:

Windows Update Standalone Installer
Installer encountered an error
The specified service does not exist as an installed service.

What is it? A standalone installer or a dependent installer?
Besides, M$, how about naming the missing service in the error message??

M$ used to turn out pretty usable stuff when they were still rather small.
:idea:I think it maybe in our own best interest to get them back to that point, by not buying any M$ products and using pirated Windows exclusively!

[MedEvil]

I was finally able, with the help of a kind soul, who sent me the driver, to run some tests and have a look, how the Turbo-Mode affects performance.

First off, the new driver does work with all USB storage devices, it however is not a driver, which magicly boosts all attached devices.

With USB storage, we have to deal with a chain of components.

Namely:
- USB Controller on the Mainboard
- USB protocol for storage devices
- Controller on the USB device
- NAND Flash or HDD

Speed in a chain like that, is always determined by the slowest link.

If your mainboard USB controller and the USB storage device can both deliver higher speeds than what the protocol allows for, the new driver + tweak will give you a huge boost in performance, for files bigger than 64kB!!!

If your device is a supermarket USB-Stick, which can not make full use of the provided bandwidth anyhow, there's no gain!

That said.
In case in your supermarket USB-Stick works a too weak controller, a controller which slows down the faster NAND Flash. Then the tweak to the protocol will reduce load on the controller and give you a minor boost of maybe 1MB/s.


So are there any situations, in which performance suffers with Turbo-Mode?

In my tests, i couldn't find any such indicators.
There was a potential drop in 4k writes, when tested with CrystalDiskMark, but it was so small that it could also be a normal fluctuation.

AttoDisk on the other hand did not show any adverse effects at any block size.


Here are two pictures, which show very nicely the impact of the new driver + tweak.

First is of a SanDisk Cruzer Contour Extreme (a pretty fast USB-Stick)

(Since this stupid board does not allow me to add images anywhere, but at the end of the post fetch it from there.)

The second of a USB-HDD

(dito)

With default settings (64kB) speed does not improve anymore with files larger than 64kB.

With Turbo-Mode settings (2MB) speed stops improving only at 2MB.

In theory (not supported by the new driver), if you would only transfer really large files and increase the MaximumTransferLength further, you might get even still a bit more performance out of the transfer.

Attached Thumbnails

• 
• 

[Wonko the Sane]

Can you please clarify on WHICH OS that thingy works?

And which actual settings are actually needed in the Registry?

The posted references seem to imply that it applies to Windows 7 (and not to earlier versions) and that the setting can (or should ) be made on a per-device basis.

 

Wonko

[MedEvil]

Well kb2581464 is only for Windows 7 and Windows Server 2008 R2, both SP0 and SP1.

Along with the new USBSTOR.SYS the following registry entry is needed:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbstor\VVVVPPPP}
"MaximumTransferLength"=dword:001fffe0

(in which VVVV stands for the VendorID and PPPP stands for the ProductID of the USB device)

The value can not be changed on the fly. USBSTOR reads the setting only when the device is attached.


I've tryed a few things, but there seems to be no way, to get the driver to enable the higher MaximumTransferLength globally.


As far as other Windows versions go.
Since this is only a small patch to the USBSTOR driver, without any other changes to the system, i can see no reason, that would speak against patching USBSTOR in an older Windows, to get the same effect.

[Wonko the Sane]

Good.

So, as expected, the article you cited originally:

http://www.tomshardw...rbo,3215-3.html

was deceiving and the correction posted on the Italian version of the article was the good one.

http://www.tomshw.it...?pag_commenti=3

 

The other resource, found by looking for the key originally cited:

http://www.blogsolut...indows-7/17866/

is definitely wrong, and a good example how thanks to mindless bloggers misinformation spreads.

 

About previous versions I was actually wondering about something slightly different : it is possible that the modified USBSTOR.SYS from the KB works "as is".

 

It would be not the first time, as an example one of the ways to have "better" USB support on Win9x is to use a Win2K USBSTOR.SYS (+other files of the USB stack), see:

http://www.msfn.org/...-on-98se-works/

 

Wonko