TurboFlash
#26
Posted 18 June 2010 - 10:59 AM
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?
#27
Posted 18 June 2010 - 11:54 AM
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" ).Think outside the box
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
#28
Posted 18 June 2010 - 01:11 PM
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.
#29
Posted 18 June 2010 - 05:02 PM
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
#30
Posted 18 June 2010 - 05:22 PM
Thanks, found amd64 in one set. Expected as much, as those drivers are the ones, which are a bit bigger than the others.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?
But always nice to be sure.
#31
Posted 18 June 2010 - 05:46 PM
Naaah, it takes most of the fun out of it.But always nice to be sure.
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
#32
Posted 18 June 2010 - 07:18 PM
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.
#33
Posted 18 June 2010 - 07:29 PM
And IF/HOW MUCH it does.Next step: Figuring out, how the driver(pair) does, what it does.
Check the FAQ's on the LaCie manual.
Wonko
#34
Posted 18 June 2010 - 07:55 PM
Since i neighter own a Lacie nor a Mushkin compatible 'drive', i would need, for that, to 'break' the software, for purely educational purposes.And IF/HOW MUCH it does.
#35
Posted 30 June 2010 - 11:24 AM
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
#36
Posted 30 June 2010 - 01:45 PM
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.
#37
Posted 30 June 2010 - 01:57 PM
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.
#38
Posted 30 June 2010 - 07:22 PM
Crystal ball:possible ways the driver could work.
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.
#39
Posted 30 June 2010 - 09:42 PM
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
#40
Posted 30 June 2010 - 09:46 PM
#41
Posted 30 June 2010 - 10:31 PM
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
#42
Posted 26 January 2013 - 02:36 PM
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.
#43
Posted 26 January 2013 - 03:26 PM
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
#44
Posted 26 January 2013 - 03:44 PM
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.
#45
Posted 26 January 2013 - 04:28 PM
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.
#46
Posted 26 January 2013 - 06:53 PM
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:
What is it? A standalone installer or a dependent installer?Windows Update Standalone Installer
Installer encountered an error
The specified service does not exist as an installed service.
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!
#47
Posted 02 February 2013 - 04:34 PM
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.
#48
Posted 02 February 2013 - 05:34 PM
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
#49
Posted 02 February 2013 - 06:34 PM
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.
#50
Posted 02 February 2013 - 07:02 PM
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
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users