32 GB memory stick

In message , Paul
writes:
[]
To make USB3 pen drives, they have a problem fitting enough Flash
channels in parallel, to achieve the same rates we see from SSD drives.
The pen drives I've seen for sale, are already pretty fat and unwieldy.

Paul

What does the "D" stand for in "SSD drives"?
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

After I'm dead I'd rather have people ask why I have no monument than why I
have
one. -Cato the Elder, statesman, soldier, and writer (234-149 BCE)

On Thu, 10 Nov 2011 21:50:40 +0000, "J. P. Gilliver (John)"
wrote:

In message , Paul
writes:
[]
To make USB3 pen drives, they have a problem fitting enough Flash
channels in parallel, to achieve the same rates we see from SSD drives.
The pen drives I've seen for sale, are already pretty fat and unwieldy.

Paul

What does the "D" stand for in "SSD drives"?

It's similar to the "C" in "NIC card".

--

Char Jackson

On 10/11/2011 21:32, R. C. White wrote:
Hi, Peter.

"Peter Jason" wrote in message
...

SNIP
Ok, sorry, I was going by the USB3 spec. I see now that the bottleneck
isn't the USB3 port but rather the device itself. If the packaging
suggests a read rate of about 135MB/sec and you're only getting
137-152 Mb/sec, then something is still wrong. (Unless you're still
confusing Mb with MB? Megabits versus Megabytes)

Now I'm confused. I need a rest.

I am not a techie, but...a non-techie refresher for anyone confused by
MB and Mb:

It takes 8 bits to make a byte, as most computer addicts know. But to
SEND a byte online, or even between disks or other devices within one
computer, the sender has to tell the receiver WHERE in the string of
bits a byte begins. So, before each batch of 8 bits it inserts a START
bit, then it ends each byte with a STOP bit, making a 10-bit
transmission for each byte. To send 1,000 bytes, the transmitter must
send 10,000 bits.

The abbreviation for "bits" is "b", the lowercase "b"; the uppercase "B"
is used for "bytes". So 135 MB/sec is 10 times as fast as 135 Mb/sec.

Simple - but oh, so easy to overlook the often-subtle difference between
"b" and "B" when reading along. :^{

RC
--

Add a parity bit and things get even bigger.

Ed

Hi, John.

SSD = Solid State Device - or Solid State Drive
NIC = Network Interface Card

I think. Char can correct me if I'm wrong. ;^}

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2011 (Build 15.4.3538.0513) in Win7 Ultimate x64 SP1


What does the "D" stand for in "SSD drives"?
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

On Thu, 10 Nov 2011 15:32:01 -0600, R. C. White wrote:

Hi, Peter.

"Peter Jason" wrote in message
...

SNIP
Ok, sorry, I was going by the USB3 spec. I see now that the bottleneck
isn't the USB3 port but rather the device itself. If the packaging
suggests a read rate of about 135MB/sec and you're only getting
137-152 Mb/sec, then something is still wrong. (Unless you're still
confusing Mb with MB? Megabits versus Megabytes)

Now I'm confused. I need a rest.

I am not a techie, but...a non-techie refresher for anyone confused by MB
and Mb:

It takes 8 bits to make a byte, as most computer addicts know. But to SEND
a byte online, or even between disks or other devices within one computer,
the sender has to tell the receiver WHERE in the string of bits a byte
begins. So, before each batch of 8 bits it inserts a START bit, then it
ends each byte with a STOP bit, making a 10-bit transmission for each byte.
To send 1,000 bytes, the transmitter must send 10,000 bits.

The abbreviation for "bits" is "b", the lowercase "b"; the uppercase "B" is
used for "bytes". So 135 MB/sec is 10 times as fast as 135 Mb/sec.

Simple - but oh, so easy to overlook the often-subtle difference between "b"
and "B" when reading along. :^{

RC

The above is true for some old serial protocols, but not used a lot
today.

All protocols have some overhead, but not as much as described above.
And the blocks are not usually eight bits any more, but more like 128 or
256 bits, in fact, often 128 or 256 data bits plus some protocol bits.

Most transmission blocks have a few byte sat the beginning giving such
things as the protocol in use, the category or type of the block, the ID
or sequence number of the block, the source and destination IDs, and in
some cases a byte count. The sequence number is especially useful when
there are multiple data streams or when there are retransmissions.

The blocks usually have, most likely at the end, a check sum or a set of
check digits designed to detect a corrupted block. If the block isn't
too corrupted, these bits may even allow reconstructing the block's
data, but if that can't be done, the receiver requests a retransmission.

Nowhere near as simple as above. And hardly new. I first worked with
that stuff around 1985; I hardly think it was new then.

The above is the best I can do for now, since 1985 is also pretty much
when I *last* worked with that stuff :-)

--
Gene E. Bloch (Stumbling Bloch)

On Thu, 10 Nov 2011 15:32:01 -0600, "R. C. White"
wrote:

I am not a techie, but...a non-techie refresher for anyone confused by MB
and Mb:

It takes 8 bits to make a byte, as most computer addicts know. But to SEND
a byte online, or even between disks or other devices within one computer,
the sender has to tell the receiver WHERE in the string of bits a byte
begins. So, before each batch of 8 bits it inserts a START bit, then it
ends each byte with a STOP bit, making a 10-bit transmission for each byte.
To send 1,000 bytes, the transmitter must send 10,000 bits.

The abbreviation for "bits" is "b", the lowercase "b"; the uppercase "B" is
used for "bytes". So 135 MB/sec is 10 times as fast as 135 Mb/sec.

Simple - but oh, so easy to overlook the often-subtle difference between "b"
and "B" when reading along. :^{

Thanks, R.C. I suppose I should have explained the 'b versus B' thing
rather than assume the OP knew what I was talking about. Thanks for
doing it.

Regarding the per-byte start, stop, and parity bits, my understanding
is that those things are pretty much a quaint bit of history that
disappeared along with dial-up modems. These days most of us (right?)
have replaced our modems with Ethernet connections that carry IP
traffic. IP data packets have headers and payload, where the payload
can be TCP, for example, which itself has headers and payload, and so
on. The whole packet will have a checksum rather than attempting to
verify the integrity of each individual byte. Then on the local (LAN)
network, everything is stuffed into Ethernet frames, and they too have
headers and payload. Even with all of that, the net result is that
there is less overhead than there was with dial-up.

That's probably simplified to the point that much of it is wrong, but
I'm going to quit while I'm behind.

--

Char Jackson

On Thu, 10 Nov 2011 18:06:06 -0600, Char Jackson wrote:

On Thu, 10 Nov 2011 15:32:01 -0600, "R. C. White"
wrote:

I am not a techie, but...a non-techie refresher for anyone confused by MB
and Mb:

It takes 8 bits to make a byte, as most computer addicts know. But to SEND
a byte online, or even between disks or other devices within one computer,
the sender has to tell the receiver WHERE in the string of bits a byte
begins. So, before each batch of 8 bits it inserts a START bit, then it
ends each byte with a STOP bit, making a 10-bit transmission for each byte.
To send 1,000 bytes, the transmitter must send 10,000 bits.

The abbreviation for "bits" is "b", the lowercase "b"; the uppercase "B" is
used for "bytes". So 135 MB/sec is 10 times as fast as 135 Mb/sec.

Simple - but oh, so easy to overlook the often-subtle difference between "b"
and "B" when reading along. :^{

Thanks, R.C. I suppose I should have explained the 'b versus B' thing
rather than assume the OP knew what I was talking about. Thanks for
doing it.

Regarding the per-byte start, stop, and parity bits, my understanding
is that those things are pretty much a quaint bit of history that
disappeared along with dial-up modems. These days most of us (right?)
have replaced our modems with Ethernet connections that carry IP
traffic. IP data packets have headers and payload, where the payload
can be TCP, for example, which itself has headers and payload, and so
on. The whole packet will have a checksum rather than attempting to
verify the integrity of each individual byte. Then on the local (LAN)
network, everything is stuffed into Ethernet frames, and they too have
headers and payload. Even with all of that, the net result is that
there is less overhead than there was with dial-up.

That's probably simplified to the point that much of it is wrong, but
I'm going to quit while I'm behind.

I think between us, with our different approaches, we have a pretty good
summary of transmission protocols.

And what we lack in details we make up for with the cogency of our
explanations :-)

I especially like that you pointed out the Matroshka nature of these
protocols (i.e., like nesting Russian dolls). Wish I'd thought of that
:-)

--
Gene E. Bloch (Stumbling Bloch)

On Thu, 10 Nov 2011 17:05:19 -0600, "R. C. White"
wrote:

Hi, John.

SSD = Solid State Device - or Solid State Drive
NIC = Network Interface Card

I think. Char can correct me if I'm wrong. ;^}

I would never do that. ;-)

--

Char Jackson

On Thu, 10 Nov 2011 16:31:09 -0800, "Gene E. Bloch"
wrote:

I think between us, with our different approaches, we have a pretty good
summary of transmission protocols.

And what we lack in details we make up for with the cogency of our
explanations :-)

I especially like that you pointed out the Matroshka nature of these
protocols (i.e., like nesting Russian dolls). Wish I'd thought of that
:-)

I ended up mostly rambling, but the tag team approach is sometimes
best. Thanks.

--

Char Jackson

In message , Char Jackson
writes:
On Thu, 10 Nov 2011 21:50:40 +0000, "J. P. Gilliver (John)"
wrote:

In message , Paul
writes:
[]
To make USB3 pen drives, they have a problem fitting enough Flash
channels in parallel, to achieve the same rates we see from SSD drives.
The pen drives I've seen for sale, are already pretty fat and unwieldy.

Paul

What does the "D" stand for in "SSD drives"?

It's similar to the "C" in "NIC card".

That's what I thought. (Another newsgroup I take refers to this as "PNS
syndrome", where PN is "PIN number".) But I'll let him off this once
because it _could_ mean "device" - though usually doesn't (-:.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

After I'm dead I'd rather have people ask why I have no monument than why I
have
one. -Cato the Elder, statesman, soldier, and writer (234-149 BCE)

In message , Gene E. Bloch
writes:
On Thu, 10 Nov 2011 15:32:01 -0600, R. C. White wrote:
[]
It takes 8 bits to make a byte, as most computer addicts know. But to SEND
a byte online, or even between disks or other devices within one computer,
the sender has to tell the receiver WHERE in the string of bits a byte
begins. So, before each batch of 8 bits it inserts a START bit, then it
ends each byte with a STOP bit, making a 10-bit transmission for each byte.
To send 1,000 bytes, the transmitter must send 10,000 bits.

Just adding a start and/or stop bit doesn't of itself help much with the
framing: to achieve that you have to add an _odd_ number of half bits.
Otherwise, depending on the data, you can go for a long time without
lining up properly.
[]
The above is true for some old serial protocols, but not used a lot
today.
[]
Indeed - modern protocols are different, and nested, as others have
said (and sometimes include sections that are either not required but
there for historical reasons, or are at least duplicated in the several
layers). But we still send bits serially - there's only one line, though
with multiphase encoding this can send several bits at once, so it would
be more accurate to say we send symbols serially - so there _is_ still a
need for _some_ method of maintaining framing. (A point often
infuriatingly omitted in papers comparing MFM, PSK, AM, and all the
others.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

After I'm dead I'd rather have people ask why I have no monument than why I
have
one. -Cato the Elder, statesman, soldier, and writer (234-149 BCE)

On Fri, 11 Nov 2011 08:08:50 +0000, "J. P. Gilliver (John)"
wrote:

That's what I thought. (Another newsgroup I take refers to this as "PNS
syndrome", where PN is "PIN number".) But I'll let him off this once
because it _could_ mean "device" - though usually doesn't (-:.
--

It is possible to have more than one PIN so PIN number could make
sense.

Steve

--
Neural network software applications, help and support.

Neural Network Software. www.npsl1.com
EasyNN-plus. Neural Networks plus. www.easynn.com
SwingNN. Forecast with Neural Networks. www.swingnn.com
JustNN. Just Neural Networks. www.justnn.com

On Fri, 11 Nov 2011 10:05:20 +0000, Stephen Wolstenholme wrote:

On Fri, 11 Nov 2011 08:08:50 +0000, "J. P. Gilliver (John)"
wrote:

That's what I thought. (Another newsgroup I take refers to this as "PNS
syndrome", where PN is "PIN number".) But I'll let him off this once
because it _could_ mean "device" - though usually doesn't (-:.
--

It is possible to have more than one PIN so PIN number could make
sense.

Steve

Now you're toying with us :-)

And I have to admit I never thought of it!

In the area where I live, a major thoroughfare is El Camino Real, and
people often refer to it as "the El Camino". Now I ask for your help in
coming up with a useful parsing of that :-)

--
Gene E. Bloch (Stumbling Bloch)

On Fri, 11 Nov 2011 08:16:32 +0000, J. P. Gilliver (John) wrote:

In message , Gene E. Bloch
writes:
On Thu, 10 Nov 2011 15:32:01 -0600, R. C. White wrote:
[]
It takes 8 bits to make a byte, as most computer addicts know. But to SEND
a byte online, or even between disks or other devices within one computer,
the sender has to tell the receiver WHERE in the string of bits a byte
begins. So, before each batch of 8 bits it inserts a START bit, then it
ends each byte with a STOP bit, making a 10-bit transmission for each byte.
To send 1,000 bytes, the transmitter must send 10,000 bits.

Just adding a start and/or stop bit doesn't of itself help much with the
framing: to achieve that you have to add an _odd_ number of half bits.
Otherwise, depending on the data, you can go for a long time without
lining up properly.
[]
The above is true for some old serial protocols, but not used a lot
today.
[]
Indeed - modern protocols are different, and nested, as others have
said (and sometimes include sections that are either not required but
there for historical reasons, or are at least duplicated in the several
layers). But we still send bits serially - there's only one line, though
with multiphase encoding this can send several bits at once, so it would
be more accurate to say we send symbols serially - so there _is_ still a
need for _some_ method of maintaining framing. (A point often
infuriatingly omitted in papers comparing MFM, PSK, AM, and all the
others.)

Of course, with the protocols we seem to be thinking of here, missing
the correct start of a block would make the block uninterpretable. The
receiver couldn't even detect a checksum error, because it wouldn't know
where the checksum is. Hence the receiver would have to ignore the
block, and hopefully, the transmitter, lacking the moral equivalent of
an ACK or a NAK, would eventually retransmit the block.

Please pardon the anthropomorphic writing - I'm just being lazy :-)

--
Gene E. Bloch (Stumbling Bloch)

On 11/11/2011 18:51, Gene E. Bloch wrote:
On Fri, 11 Nov 2011 10:05:20 +0000, Stephen Wolstenholme wrote:

On Fri, 11 Nov 2011 08:08:50 +0000, "J. P. Gilliver (John)"
wrote:

That's what I thought. (Another newsgroup I take refers to this as "PNS
syndrome", where PN is "PIN number".) But I'll let him off this once
because it _could_ mean "device" - though usually doesn't (-:.
--

It is possible to have more than one PIN so PIN number could make
sense.

Steve

Now you're toying with us :-)

And I have to admit I never thought of it!

In the area where I live, a major thoroughfare is El Camino Real, and
people often refer to it as "the El Camino". Now I ask for your help in
coming up with a useful parsing of that :-)


I see completely what you mean. Here's another in the same category.
Is Las Vegas a good town?
Is Buenos Aires near Rio? Are the airs good there?

Ed