CF Card Images and Linux

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

CF Card Images and Linux

Postby BeebMaster » Fri Apr 18, 2014 6:31 pm

I'm getting to grips with imaging my ADFS formatted CF cards in Linux, using dd, then converting the image to something useable by throwing away every other null byte using a script that somebody on the Ubuntu forums wrote for me. I can then use that image as a proper ADFS image and mount it in ADFS Fuse or read it with ADFS Explorer running under Wine.

It's taken me nearly five years to get this far, so I'm glad I've got it sussed.

What I haven't got sussed yet is how to convert a "real" ADFS image back to an image padded with alternate null bytes so that I can write it back to the CF card and have it work in the Beeb.

Can anyone help? I'm not sure if I've ever posted the code I was given to do the stripping, so it's here:

Code: Select all

#!/usr/bin/perl

$srcfile = shift(@ARGV);
$dstfile = shift(@ARGV);

open(FILE, $srcfile) or die "can't open $srcfile: $!";
open(DST,">".$dstfile) or die "can't open $dstfile: $!";

binmode(FILE);
binmode(DST);
$even_flag = 1;
while (read(FILE, $buff, 128*1024)) {
    foreach (split(//, $buff)) {
        if ($even_flag){
             print DST $_;
        }
        $even_flag = !$even_flag;
    }
}

close(FILE);
close(DST);


I've absolutely no idea what it means, but it works, although it is very slow - takes about an hour to do a 2*512MB ADFS card.

If anyone can improve that as well, that would be great!
Image

User avatar
jgharston
Posts: 2727
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: CF Card Images and Linux

Postby jgharston » Fri Apr 18, 2014 6:49 pm

BeebMaster wrote:What I haven't got sussed yet is how to convert a "real" ADFS image back to an image padded with alternate null bytes so that I can write it back to the CF card and have it work in the Beeb.
You want an optimised version of whatever is the equivalent of:

Code: Select all

in%=OPENIN(infile$)
out%=OPENOUT(outfile$)
REPEAT
  byte%=BGET#in%
  BPUT#out%,byte%
  BPUT#out%,0
UNTIL EOF#in%
CLOSE#out%
CLOSE#in%


Having a guess looking at the code:

Code: Select all

#!/usr/bin/perl

$srcfile = shift(@ARGV);
$dstfile = shift(@ARGV);

open(FILE, $srcfile) or die "can't open $srcfile: $!";
open(DST,">".$dstfile) or die "can't open $dstfile: $!";

binmode(FILE);
binmode(DST);
while (read(FILE, $buff, 128*1024)) {
    foreach (split(//, $buff)) {
         print DST $_;
         print DST 0;
    }
}

close(FILE);
close(DST);

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Fri Apr 18, 2014 8:04 pm

Thank you very much! It just needed one tweak, I found that using PRINT 0 actually writes an ASCII character "0", so every second byte came out as &30. I don't think it would have made a difference since these are all ignored, but I've altered it to PRINT CHR(0) which uses a zero byte.

I've looked at the output in GHex and it seems to have worked correctly; I haven't written it to a CF card yet, I'm just backing up the card I am going to use at the minute, it's the only "spare" card I have at present.
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 12:46 am

BeebMaster wrote:I've absolutely no idea what it means, but it works, although it is very slow - takes about an hour to do a 2*512MB ADFS card.

That code reads data 128K at a time, and writes out every other byte to the output file.

Hmmm... I know I wrote code to do this, but I can't find it now!

if you want to send me your raw datafile, I'll see how quick I can get a program to process it. I'm pretty sure my variant only took a few seconds. If the image is too large for an attachment then sweh at spuddy dot org or stick it on a website I can grab it from or something :-)

Adding the padding back will be easy as well.
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 12:48 am

jgharston wrote: print DST 0;

Close; that's write an actual "0" (0x30) character. You want

Code: Select all

print DST "\0";

to get ASCII NUL.

(It probably doesn't matter 'cos I expect the CF adapters just ignore the odd bytes, but might as well do it right :-))
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 11:19 am

BeebMaster wrote:I've absolutely no idea what it means, but it works, although it is very slow - takes about an hour to do a 2*512MB ADFS card.

I'm really surprised it's so slow. I just wrote a very very simple unpadder and it only took 3 minutes to convert a 1Gb CF image.

Copy the CF card to the hard disk

Code: Select all

$ time sudo dd if=/dev/sdc of=raw_image
2001888+0 records in
2001888+0 records out
1024966656 bytes (1.0 GB) copied, 54.7226 s, 18.7 MB/s

real   0m55.08s
user   0m1.27s
sys   0m13.01s
$


Here's the raw image:

Code: Select all

$ ls -lh raw_image
-rw-r--r-- 1 root root 978M Apr 19 06:52 raw_image

Let's look at it...

Code: Select all

$ hdump raw_image | head -10000 | grep H.u.g.o
0000da80  48 FF 75 FF 67 FF 6F FF   H.u.g.o.
000108d0  48 FF 75 FF 67 FF 6F FF   H.u.g.o.
$

We can see the ADFS "Hugo" markers. In this case it looks like the padding byte is FF, but it doesn't really matter.

Let's strip the padding byte:

Code: Select all

$ time ./unpad.pl < raw_image > result

real    2m46.86s
user    2m42.33s
sys     0m1.11s
$

And here's the result:

Code: Select all

$ ls -lh result
-rw-r--r-- 1 sweh sweh 489M Apr 19 07:00 result
$ hdump result  | head -10000 | grep Hugo     
00000200  23 48 75 67 6F A1 C2 4F   #Hugo..O
000006f8  00 00 23 48 75 67 6F 00   ..#Hugo.
00006d40  48 75 67 6F 00 C6 3D 00   Hugo..=.
00008448  FF 92 48 75 67 6F 00 C6   ..Hugo..
00008468  48 75 67 6F 00 E8 E8 86   Hugo....

The code to do this is very simple.

Code: Select all

#!/usr/bin/perl

my $ch;

while (read(STDIN,$ch1,1))
{
  print $ch1;
  # Now read and discard the pad
  read(STDIN,$ch1,1);
}

To re-pad:

Code: Select all

#!/usr/bin/perl

my $ch;

while (read(STDIN,$ch1,1))
{
  print $ch1;
  # Now add the padding character
  print "\xff";
}

Pick whatever character you want as padding; here I used FF to match what was in my original. Use 00 if that's what you want to pad.

Test:

Code: Select all

$ time ./repad.pl < result > new

real   2m23.18s
user   2m18.20s
sys   0m1.30s
$ cmp raw_image new
raw_image new differ: char 151554, line 560

Interesting! It's different. Bug? Let's investigate...

Code: Select all

$ hcmp raw_image new | head
25001  00    FF 
25003  00    FF 
25005  00    FF 
25007  00    FF 
25009  00    FF 
2500b  00    FF 
2500d  00    FF 
2500f  00    FF 
25011  00    FF 
25013  00    FF 
$

So data is different. Let's look at the raw file again...

Code: Select all

$ hdump raw_image | grep ^000250[0-3]
00025000  79 00 20 00 6F 00 70 00   y. .o.p.
00025008  65 00 6E 00 20 00 66 00   e.n. .f.
00025010  69 00 6C 00 65 00 73 00   i.l.e.s.
00025018  0D 00 B8 00 54 00 6F 00   ....T.o.
00025020  6F 00 20 00 6D 00 61 00   o. .m.a.
00025028  6E 00 79 00 20 00 75 00   n.y. .u.
00025030  73 00 65 00 72 00 73 00   s.e.r.s.
00025038  0D 00 B5 00 49 00 73 00   ....I.s.

Ha! The padding has changed! The original file was inconsistent with the padding byte. That means we'll never be able to compare. Ah well...

I'm still surprised your original code was so slow, though. I'd expect it to be faster!

Hmm, were you reading from the CF directly, or from an image file? dd'ing the CF card to an image may be faster then reading the CF directly.
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 11:42 am

Wow, OK, that old code you had is slow. Not "hour long" but it took 5m43s on my machine, which is twice as long as the simple code.

Which is odd. What the author of that code attempted to do is minimise the number of read() calls, so it reads data 128K at a time. However it looks like splitting that stream into bytes with split() and the logic to skip every other byte was worse than hitting read() 128,000 times more often!

This is a case where attempted optimisation actually resulted in poorer performance. Heh!

(Perl read() actually calls the OS fread() routine, and so uses STDIO; it's possible that STDIO buffering helped the simple code, here)
Rgds
Stephen

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 1:44 pm

The 128K business is possibly my doing, I experimented with various different "block sizes" to try to find the optimum speed and the 128K version is the one I'd settled on as being the quickest. I was always surprised it was so slow, I even tried a few other things like trying to process the data using a RAM disc instead of having to read from the hard drive a byte at a time, but it didn't help.

I can't remember now where I am up to with the timings of everything so I'll do a few experiments with my code and the new code to compare the two.
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 3:13 pm

BeebMaster wrote:I even tried a few other things like trying to process the data using a RAM disc instead of having to read from the hard drive a byte at a time, but it didn't help.

Well, you don't read from the hard drive a byte at a time. The OS would load a datablock into memory (probably 2K). Now if you'd used perl sysread() [ aka Unix read(2) ] then there would have been 128K context switches saved as the program switched in/out of kernel mode to read a byte from the buffer. However you used perl read() [ aka Unix fread(3) ] which uses STDIO. Now a quick wander through /usr/include and I think Linux STDIO buffers are actually 8K in size so your reading 128K at a time really only saves 15 trips to the hard disk, and probably doesn't save any context switches. I can well see how this efficiency gain could be lost by split() and the extra if test and variable setting.
Rgds
Stephen

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 4:15 pm

I've made a test image, this is a direct copy of a 1GB image read in from a CF card in December, effectively it's the "ADFS drive 0 512MB" part of the CF card.

With the old code:

Code: Select all

time ./Converter128K.pl TestImage.dat TestImageunpad.dat

real   25m6.107s
user   24m48.285s
sys   0m10.941s


Trying out the new code now.
Image

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 4:29 pm

10 minutes faster, but still pretty slow?

Code: Select all

time ./Unpad.pl < TestImage.dat > TestImageunpad.dat

real   15m41.435s
user   15m23.842s
sys   0m9.501s


What are the "<" and ">" for? It doesn't work without.
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 4:46 pm

My program is a simple "filter" that reads from stdin and writes to stdout. "<" means "redirect stdin from file" and ">" means "send stdout to file" (This is standard Unix redirection; also works with command.com and cmd.exe on Windows).

So, for example, it would be possible to do

Code: Select all

dd if=/dev/sdc | ./unpad.pl > adfs_file

(or whatever device your CF card shows up as) and read from CF, remove the extra byte and send create the file all in one go.

Similarly,

Code: Select all

./repad.pl < adfs_file  | dd of=/dev/sdc

would take an ADFS file, add the padding and write it back to CF.
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 5:02 pm

BeebMaster wrote:10 minutes faster, but still pretty slow?

Code: Select all

time ./Unpad.pl < TestImage.dat > TestImageunpad.dat

real   15m41.435s
user   15m23.842s
sys   0m9.501s

Was your TestImage.dat file a 1Gb file or a 2Gb file?

If it was a 1Gb file then your machine appears to be 6 times slower than mine. This might be CPU speed related, or it might be disk I/O related. Is your Unix machine a physical machine, or a virtual machine? If it's a VM then it's very possibly I/O speed. If you've not got the right drivers loaded then the VM may be inefficient for network and disk.

Although since it's spending most of the time in "user" then it's probably really CPU bound.

Or you might just have an older machine than mine; my machine is 3 years old but still plenty fast enough for my needs :-) It's a quad-core AMD Phenom @ 2.8Ghz, but this program only uses one core. When it's running one core is fully loaded, but the other 3 are idle.

Code: Select all

% grep MHz /proc/cpuinfo
cpu MHz      : 2800.000
cpu MHz      : 800.000
cpu MHz      : 800.000
cpu MHz      : 800.000

We can see only 1 core is being used for this task :-)

If you have a slower CPU then it will take longer.
Rgds
Stephen

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 5:13 pm

It's a 1GB file (equivalent to an ADFS drive of 512MB). The first time I had Thunderbird and Firefox running, and a couple of Thunar windows open. I did it again with everything closed apart from the terminal window doing the unpadding. A bit quicker:

Code: Select all

time ./Unpad.pl < TestImage.dat > TestImageunpad.dat

real   14m39.109s
user   14m29.742s
sys   0m5.476s


I'm doing all this on my little notebook, which I bought in April 2011. It's the newest machine at BM Towers, and it runs Ubuntu 12.04.

I did the grep thing, but whilst it's idle:

Code: Select all

grep MHz /proc/cpuinfo
cpu MHz      : 1000.000
cpu MHz      : 1000.000
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 5:17 pm

So I just ran both versions of code using "time -v".

With your code I can see

Code: Select all

   Maximum resident set size (kbytes): 53424
   Voluntary context switches: 29
   File system inputs: 208
   File system outputs: 1001472


With my code I see

Code: Select all

   Maximum resident set size (kbytes): 7104
   Voluntary context switches: 1012
   File system inputs: 23576
   File system outputs: 1001472

We can see that file system output is the same; to be expected 'cos we're both just "print"ing. (Hmm, I wonder if that's a kernel bug; the number seems to be twice what I expect).

We can see the benefit your "reading in chunks" has in terms of context switches and "file sytem inputs" (I'm doing more than I expected). And, of course, you need more memory; quite a lot more! The temporary array built from the split() isn't friendly, it appears! But both pieces of code spend most of their time in userspace:
You: User time (seconds): 331.85
Me: User time (seconds): 166.95

So I think both pieces of code are CPU bound.
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 5:18 pm

BeebMaster wrote:I did the grep thing, but whilst it's idle:

Code: Select all

grep MHz /proc/cpuinfo
cpu MHz      : 1000.000
cpu MHz      : 1000.000

Yeah, modern Linux distro's slow down CPUs when they're not in use. Mine slows to 800Mhz. You need to run it while the proces is running to see what the CPU ramps up to.
Rgds
Stephen

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 5:27 pm

Did it again whilst it was unpadding, a few times. Most of the time it was:

Code: Select all

grep MHz /proc/cpuinfo
cpu MHz      : 1666.000
cpu MHz      : 1000.000


Once or twice:

Code: Select all

grep MHz /proc/cpuinfo
cpu MHz      : 1000.000
cpu MHz      : 1666.000
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 5:48 pm

BeebMaster wrote:cpu MHz : 1666.000

OK, so you've got a 1.6Ghz CPU. That's a fair bit slower than mine and will account for maybe half the difference. The other half may be disk speed, or free memory used for disk I/O cache; I have 6Gb RAM in my machine, so writing 500M of data will all go into I/O cache and only flushed during the kernel periodic flushes. If you don't have as much free RAM then it's possible you'll be doing physical disk I/O more often. And laptop disks of that era are typically slower than desktop disks (it's one reason why I don't have a work laptop; desktops are just that much faster!)
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 5:55 pm

Some gross performance analysis... I ran your code with various bits commented out.

Commenting the whole for loop, took 0.42s. Well, that's how long it takes to read the data :-)

Adding in the for loop but commenting out the if test and assignment we go up to 2m53. So that's how long it takes to do all those split() calls. I then added in the assignment, but left out the if test; time went up to 4m10. So calling "$even_flag = !$even_flag;" a million times takes 1m23 seconds ;-) And then we know the whole thing took about 5m55 so the if/print section took 1m45.

Clearly the split() is the most expensive operation; that, along, takes a long as the simple approach in total!
Rgds
Stephen

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 6:10 pm

I just tried it on the next newest BM machine, the downstairs desktop, and the unpad took 7min 25, so that's already twice as quick as using the notebook!

Grep CPU only has one line, and it's c. 2700MHz.

Next I will try the 2003 BM PC, I expect it will take about 4 hours.
Image

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 6:33 pm

Well, well! BM PC, with a lowly CPU of 2083MHz, running Ubuntu 10.10, did the unpad in 7min 33!

So the old ones are the best! But then, we all knew that already on here, eh?
Image

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 7:04 pm

Final thing for the moment - imaging the card itself prior to the unpadding. I use dd and a USB Compact Flash reader (actually a multi-reader), there's no CF hole in any PC here.

Kingston6 is the CF card I have allocated for my floppy disc images, I actually made a 256MB ADFS drive as drive 0 to speed up the imaging and unpadding process, but for the purposes of this test I have read in 1GB of data, as if it was a 512MB partition.

Notebook gives:

Code: Select all

 sudo dd if=/dev/sdb of=Kingston6.dat bs=512 count=2097152
[sudo] password for beebmaster:
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 116.915 s, 9.2 MB/s


BM PC is actually fractionally quicker, at 116.555s!

At under 2 mins, I can cope with that.

I bought the current card reader a couple of months ago, the previous one was really, really slow, I think I was getting 1MB/s transfer rate, so it did take an hour to do a whole 4GB card (which isn't necessary to do, only the first 2GB of any card will have any ADFS data on it, but I don't think I knew that initially.)
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 7:07 pm

BeebMaster wrote:

Code: Select all

 sudo dd if=/dev/sdb of=Kingston6.dat bs=512 count=2097152


This is one case where increasing blocksize(bs) may improve on speed; definitely worth playing with that.
Rgds
Stephen

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 7:21 pm

I thought that, although I may have experimented before. I think your example at the beginning uses 512bps though.
Image

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 7:32 pm

Something going on with USB ports on the BM notebook. When I did the dd just now, I used the CF card reader in the right-hand USB hole. I don't normally use that one, being cack-handed I usually use one of the two on the left-hand side.

In the top left-hand slot THIS happens:


Code: Select all

sudo dd if=/dev/sdb of=Kingston6-2.dat bs=512 count=2097152
[sudo] password for beebmaster:
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 1035.22 s, 1.0 MB/s


Using the bottom left-hand slot it's 114s, even faster than the right-hand one!

I'm trying the old card reader next, to see if a written apology and an official pardon is warranted!
Image

User avatar
1024MAK
Posts: 6729
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: CF Card Images and Linux

Postby 1024MAK » Sat Apr 19, 2014 7:37 pm

Some USB ports on computers are actually via on-board integrated USB hubs. Sometimes some USB ports are indeed slower.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 7:39 pm

Well, the old reader only does 1MB/sec in all three slots, I abandoned it after c. 30MB as I could see how slow it was going.

I'll try a bigger block size with the new reader and see if I can improve on 9.2MB/s.
Image

User avatar
BeebMaster
Posts: 2470
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: CF Card Images and Linux

Postby BeebMaster » Sat Apr 19, 2014 7:45 pm

1024MAK wrote:Some USB ports on computers are actually via on-board integrated USB hubs. Sometimes some USB ports are indeed slower.

Mark

I think I'm going to block up that really slow one with blue tack, it's really annoyed me, that has! That's the one I always use!
Image

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 8:12 pm

1024MAK wrote:Some USB ports on computers are actually via on-board integrated USB hubs. Sometimes some USB ports are indeed slower.

Mark

A hub isn't really too much of a problem; USB allows for hubs without noticable degradation of speed. Some machines of that age (not common, but some still existed) had some USB-1 ports and some USB-2 ports. 1MB/s is 8Mbit/s which is close to the USB-1 limit (12Mbit/s). USB-2 can go to 480Mbit/s, and I think can sustain 240Mbit/s (35MB/s).

It really sounds like you have 1*USB1 and 2*USB2 ports on that machine.
Rgds
Stephen

User avatar
sweh
Posts: 1842
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CF Card Images and Linux

Postby sweh » Sat Apr 19, 2014 8:13 pm

BeebMaster wrote:I thought that, although I may have experimented before. I think your example at the beginning uses 512bps though.

Yes it does; I was getting
1024966656 bytes (1.0 GB) copied, 54.7226 s, 18.7 MB/s
and didn't feel the need to experiment any further on that bit :-)
Rgds
Stephen


Return to “software & utilities for the pc, mac or unix”

Who is online

Users browsing this forum: No registered users and 1 guest