Archived from groups: comp.sys.palmtops.pilot (More info?)
In article <MPG.1b1857775bbccbc6989722@news.frontiernet.net>, Jim Anderson
<fro2750@frontiernet.my_finger.net> wrote:
> On Fri, 21 May 2004 21:14:30 +0200, Erik Marchee had this to say...
>
>
> > Does it make sence to buy high speed SD-cards for my Palm Tungsten|T?
> >
> > Erik
> >
>
> Yes.
Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
higher-speed card does nothing for you.
Archived from groups: comp.sys.palmtops.pilot (More info?)
On 22-May-2004, guy@ether.net (Guy Bannis) wrote:
> > On Fri, 21 May 2004 21:14:30 +0200, Erik Marchee had this to say...
> >
> >
> > > Does it make sence to buy high speed SD-cards for my Palm Tungsten|T?
> > >
> > > Erik
> > >
> >
> > Yes.
>
> Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
> higher-speed card does nothing for you.
That is is pretty obvious answer, a better question might be: does anyone
know the actual transfer speed of the SD card slot and current speeds for SD
cards?
Archived from groups: comp.sys.palmtops.pilot (More info?)
In article <40aea1c7$1@funnel.arach.net.au>, nomail@here.com wrote:
> On 22-May-2004, guy@ether.net (Guy Bannis) wrote:
>
> > > On Fri, 21 May 2004 21:14:30 +0200, Erik Marchee had this to say...
> > >
> > >
> > > > Does it make sence to buy high speed SD-cards for my Palm Tungsten|T?
> > > >
> > > > Erik
> > > >
> > >
> > > Yes.
> >
> > Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
> > higher-speed card does nothing for you.
>
> That is is pretty obvious answer, a better question might be: does anyone
> know the actual transfer speed of the SD card slot and current speeds for SD
> cards?
>
> Cuba
Obvious to whom? Apparently not to two other people.
Archived from groups: comp.sys.palmtops.pilot (More info?)
On 22-May-2004, guy@ether.net (Guy Bannis) wrote:
> In article <40aea1c7$1@funnel.arach.net.au>, nomail@here.com wrote:
>
> > On 22-May-2004, guy@ether.net (Guy Bannis) wrote:
> >
> > > > On Fri, 21 May 2004 21:14:30 +0200, Erik Marchee had this to say...
> > > >
> > > >
> > > > > Does it make sence to buy high speed SD-cards for my Palm
> > > > >Tungsten|T?
> > > > >
> > > > > Erik
> > > > >
> > > >
> > > > Yes.
> > >
> > > Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
> > > higher-speed card does nothing for you.
> >
> > That is is pretty obvious answer, a better question might be: does
> > anyone know the actual transfer speed of the SD card slot and current
> > speeds for SD cards?
> >
> > Cuba
>
> Obvious to whom? Apparently not to two other people.
I think my question is what the original poster was asking.
Archived from groups: comp.sys.palmtops.pilot (More info?)
In message <djiua09sfk8t68o6iv38oh05bh345dmi31@4ax.com>,
WilliamP.N.Smith@?.?.invalid writes
>guy@ether.net (Guy Bannis) wrote:
>>Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
>>higher-speed card does nothing for you.
>
>OK, does anyone know if the I/O on the T3 is the bottleneck? Will a
>high-speed card be better/stronger/faster than a 'normal' speed card?
>
I've experienced significant problems with San-disk 128k SD, solved
completely by using Toshiba/ Jessop SD. In the UK San-disk appears a lot
of time whenever an SD is illustrated in the PDA press- I wonder why?
Significant problems means failing applications including the built-in
Card function. This is on both Tungsten T and T3 - I understand it
applies to others as well tho' can't define this.
Archived from groups: comp.sys.palmtops.pilot (More info?)
William wrote:
> guy@ether.net (Guy Bannis) wrote:
>
>>Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
>>higher-speed card does nothing for you.
>
>
> OK, does anyone know if the I/O on the T3 is the bottleneck?
Yes. When accessing the SD Card, I/O is the bottleneck. What
else *could* be the bottleneck?
Archived from groups: comp.sys.palmtops.pilot (More info?)
Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
>Yes. When accessing the SD Card, I/O is the bottleneck. What
>else *could* be the bottleneck?
Well, CPU speed comes to mind. Software overhead could be driving the
hardware in such a way that the actual speed of the hardware is
irrrelevant, you are never going to get more than X bytes per second
out of it...
The real question is "Has anyone tried cards from a single vendor and
discovered any speedup using "high-speed" SD cards?
Archived from groups: comp.sys.palmtops.pilot (More info?)
In article <VsYrc.12793$Hh.6596@fe1.texas.rr.com>, Logan Shaw
<lshaw-usenet@austin.rr.com> wrote:
> William wrote:
>
> > guy@ether.net (Guy Bannis) wrote:
> >
> >>Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
> >>higher-speed card does nothing for you.
> >
> >
> > OK, does anyone know if the I/O on the T3 is the bottleneck?
>
> Yes. When accessing the SD Card, I/O is the bottleneck. What
> else *could* be the bottleneck?
Archived from groups: comp.sys.palmtops.pilot (More info?)
Basil Stephens wrote:
> In message <djiua09sfk8t68o6iv38oh05bh345dmi31@4ax.com>,
> WilliamP.N.Smith@?.?.invalid writes
>
>> guy@ether.net (Guy Bannis) wrote:
>>
>>> Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
>>> higher-speed card does nothing for you.
>>
>>
>> OK, does anyone know if the I/O on the T3 is the bottleneck? Will a
>> high-speed card be better/stronger/faster than a 'normal' speed card?
>>
> I've experienced significant problems with San-disk 128k SD, solved
> completely by using Toshiba/ Jessop SD. In the UK San-disk appears a lot
> of time whenever an SD is illustrated in the PDA press- I wonder why?
>
All my Sandisk problems disappeared when I installed the T3-update from
PalmOne's support Web-site. You might give it a try.
Archived from groups: comp.sys.palmtops.pilot (More info?)
As I have the update installed and the Sandisk I retried it:
The Palm Card Info shows the card correctly as 256M and then goes into a
"Please wait" (endless) loop. The Toshiba SD works with this utility
quickly (1-2Seconds) and completely.
In message <3oksc.3627$RL3.73648@news2.e.nsc.no>, fm
<postmaster@127.0.0.1> writes
>Basil Stephens wrote:
>> In message <djiua09sfk8t68o6iv38oh05bh345dmi31@4ax.com>,
>>WilliamP.N.Smith@?.?.invalid writes
>>
>>> guy@ether.net (Guy Bannis) wrote:
>>>
>>>> Only if the I/O on the Tungsten is not the bottleneck. Otherwise, a
>>>> higher-speed card does nothing for you.
>>>
>>>
>>> OK, does anyone know if the I/O on the T3 is the bottleneck? Will a
>>> high-speed card be better/stronger/faster than a 'normal' speed card?
>>>
>> I've experienced significant problems with San-disk 128k SD, solved
>>completely by using Toshiba/ Jessop SD. In the UK San-disk appears a
>>lot of time whenever an SD is illustrated in the PDA press- I wonder why?
>>
>All my Sandisk problems disappeared when I installed the T3-update from
>PalmOne's support Web-site. You might give it a try.
Archived from groups: comp.sys.palmtops.pilot (More info?)
William wrote:
> Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
>
>>Yes. When accessing the SD Card, I/O is the bottleneck. What
>>else *could* be the bottleneck?
>
>
> Well, CPU speed comes to mind. Software overhead could be driving the
> hardware in such a way that the actual speed of the hardware is
> irrrelevant, you are never going to get more than X bytes per second
> out of it...
No DMA is a big one here. Data has to be copied word by word[1], using
the CPU.
[1] A long word move is really two adjacent word moves on a m68000.
You can shave off some instruction cycles and wait-for-next-window
latency by using move.l, and even more by using movem.l for large
copies, but it's still going to be slow.
Archived from groups: comp.sys.palmtops.pilot (More info?)
William wrote:
> Arthur Hagen <art@broomstick.com> wrote:
>
>>[1] A long word move is really two adjacent word moves on a m68000.
> Any chance the T3 could be sped up by an ARM-let, or some better
> coding?
As far as I know, there is no better way to implement copying on a
68000 than by doing a movem, assuming you use the largest register
list possible.
But this probably isn't relevant on the T3, since the stuff that
accesses the SD Card isn't an app and there is no reason it has
to be 68000 code running under PACE in the first place. In other
words, there is no reason this can't be native code on the T3;
all the internal OS code should be running as native ARM code.
Archived from groups: comp.sys.palmtops.pilot (More info?)
Guy Bannis wrote:
> In article <VsYrc.12793$Hh.6596@fe1.texas.rr.com>, Logan Shaw
> <lshaw-usenet@austin.rr.com> wrote:
>>William wrote:
>>>OK, does anyone know if the I/O on the T3 is the bottleneck?
>>Yes. When accessing the SD Card, I/O is the bottleneck. What
>>else *could* be the bottleneck?
> Read/write on the card itself. The CPU. Etc.
Well, that was sort of my point. These are all parts of I/O. I/O is
what you call it when all of the pieces work together to cause input
and output to happen. Thus, I couldn't make sense of the wording
"does anyone know if I/O is the bottleneck". To me, it was about like
saying, "does anyone know if the potential difference I have between
these two electrodes is the reason why I'm seeing a voltage?".
I was trying to ask for people to clarify what they mean by "I/O".
For instance, does it mean the maximum theoretical data rate (i.e.
clock * bus width) for the T3's SD Card interface hardware, or does
it mean something different?
Archived from groups: comp.sys.palmtops.pilot (More info?)
William wrote:
> Arthur Hagen <art@broomstick.com> wrote:
>
>>[1] A long word move is really two adjacent word moves on a m68000.
>
>
> Any chance the T3 could be sped up by an ARM-let, or some better
> coding?
Well, the emulator sure can analyse the moves and group them together
for better memory access on an ARM, but the extra code spent doing that
would probably add too much overhead for small memory operations (just
to find out if it's a small memory operation)...
With ARMlets, yes, you can get around most of the limitations of the
m68k architecture, but for most memory access (except heap memory),
there's really no "raw" access, and you have to call the libraries to
ensure atomic operations.
For IO, there could probably be some nice savings by using ARM specific
code and outside-OS buffer memory with DMA-like access. I believe
that's part of what Sony does with its "Handheld Engine", which greatly
increases display IO speed, despite the CPU itself being rather slow
(8-123MHz).
Archived from groups: comp.sys.palmtops.pilot (More info?)
Logan Shaw wrote:
>
> As far as I know, there is no better way to implement copying on a
> 68000 than by doing a movem, assuming you use the largest register
> list possible.
Mostly correct -- at least for the 68000 (which the DragonBall CPUs are
most similar to) and 68020.
For the m68030, there's some situations where it's faster to do multiple
move.l instructions in a loop, due to branches being especially
expensive, and the 68040+ have some extra instructions for longer moves.
The real odd balls out are the 68010/68012 CPUs, which have a 6 byte
prefetch latch (think 0 latency L1 cache), making a dbXX-loop especially
effective. In certain circumstances, this can be the faster choice.
I've never been able to ascertain whether any of the Dragonball CPUs
have this prefetch latch.
Archived from groups: comp.sys.palmtops.pilot (More info?)
Arthur Hagen wrote:
> For IO, there could probably be some nice savings by using ARM specific
> code and outside-OS buffer memory with DMA-like access.
Speaking of which, it seems like the OS doesn't do a whole helluva lot
to cache blocks of data from the SD Card. There are plenty of operating
systems out there (like Solaris for instance) where the unallocated
RAM is used as a buffer cache. So if you have 1 GB of ram and user
programs have only allocated 256 MB, then you have a 768 MB disk read
cache. When programs allocate memory, pages from the read cache are
automatically used as free memory (for malloc(), etc.) if necessary
so that using the unallocated-memory-as-disk-cache doesn't ever
prevent you from being able to allocate it normally. The only negative
is extra overhead and latency for all the processing necessary to
re-purpose the memory from disk cache to regular malloc()-able RAM.
(And latency can be mitigated by keeping a pool of truly free
memory and using high-water and low-water marks to try to ensure
the pool never gets completely empty.)
Aaaanyway, based on subjective experience, I would have to guess
that the Palm does little caching or possibly no caching of data
on the SD Card. I know, I know: the very concept of a filesystem
is sort of cobbled onto Palm OS as an afterthought, but it still
seems like free space (in the storage heap, or everywhere if the
underlying memory model is unified) could be used to cache SD Card
reads with almost no ill effects and huge positive effects. Imagine
not having to see "Please wait" when you go to the SD Card category
in the launcher, for instance.
Of course, I could be wrong about there being virtually no caching.
Maybe there's a cache, but it's a small fixed size. Or maybe I just
have old devices and this has been implemented in the latest OS 5.x
release. (Or maybe it's coming with OS 6...)
Archived from groups: comp.sys.palmtops.pilot (More info?)
Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
> >>>OK, does anyone know if the I/O on the T3 is the bottleneck?
>
> >>Yes. When accessing the SD Card, I/O is the bottleneck. What
> >>else *could* be the bottleneck?
>
> > Read/write on the card itself. The CPU. Etc.
>
> Well, that was sort of my point.
Then your point...um...missed the point.
The original question was about the I/O on the T3 itself. That's a
specific piece of the system. I don't have the answer, so I can't help,
but at least I understand the question.
Archived from groups: comp.sys.palmtops.pilot (More info?)
On Sun, 23 May 2004 07:33:09 GMT, Logan Shaw
<lshaw-usenet@austin.rr.com> was understood to have stated the
following:
>> OK, does anyone know if the I/O on the T3 is the bottleneck?
>
>Yes. When accessing the SD Card, I/O is the bottleneck. What
>else *could* be the bottleneck?
I think his question is "Is the T3's maximum bandwidth lower than the
(type of card here)'s bandwidth?" If the T3' bandwidth is lower than
that of your "average" card, it makes no sense to pay a premium price
for a capacity you won't benefit from.
That being said, here are some benchmarks from the cards I have;
sorry, they are ordered by the date the benchmarks were performed, and
they were performed in the order of purchase
2004-05-10 12:19:24
Monday
VFSMark ResultsWPj05(Panasonic 256SD(gold))
File Create: 480%
File Delete: 300%
File Write: 134%
File Read: 692%
File Seek: 983%
DB Export: 238%
DB Import: 829%
Record Access: 709%
Resource Access: 662%
Archived from groups: comp.sys.palmtops.pilot (More info?)
William P.N. Smith wrote in message news:<14s8b0dsfjt4abj1scve0078fern9tcoab@4ax.com>...
> "David W. Poole, Jr." <SpammersAreLosers.20.dwpj65@spamgourmet.com>
> wrote:
>
> >VFSMark ResultsWPj05(Panasonic 256SD(gold)) VFSMark: 558
> >VFSMark ResultsWPj07(Lexar 32SD) VFSMark: 306
> >VFSMark ResultsWPj02(SanDisc 32MMC) VFSMark: 195
> >VFSMark ResultsWPj06(Panasonic 32SD) VFSMark: 546
> >VFSMark ResultsWPj04(Panasonic 16SD) VFSMark: 431
> >VFSMark ResultsWPj03(Panasonic 256SD(Silver)) VFSMark: 515
> >VFSMark ResultsWPj01(Panasonic 256SD(Silver)) VFSMark: 484
> >DWPj08(Pansonic 512mb) VFSMark: 607
> >VFSMark Results: DWPj09(Panasonic 512mb) VFSMark: 618
> >DWPj10(Panasonic 64mb) VFSMark: 431
>
> >So it appears there is some benefit in purchasing high speed cards.
>
> Which of the above are "high speed" cards, and which Palm were the
> tests run on?
>
> Thanks!
I don't really know which of the cards is high-speed or not, as they
are not labeled as such. I can say that I *believe* the color of the
labeling on the Panasonic cards is an indication of their speed. That
being stated, the 512mb'ers are gold, and all cards less than 256mb
are silver; the 256'ers are the only ones I've got that are "mixed",
and I regret not having purchased more gold 256'ers.
The most "significant" differentials I've noticed are the file writes,
an issue of importance to me as my cards get triple usage: data
transport from PC to PC, camera, and PDA. The camera is where the
write speed means the most to me. The differentials of the read speeds
seems relativily insignificant, in my opinion, to that of the write
speeds.
To the OP of this thread, as to whether or not the the high speed
cards are worth the extra cost, it's a subjective issue. You would
have to weigh what your card's utilization is. If the major advantage
of having a fast card is reduced write times, read times are nearly
the same, and most of your applications are going to be primarily
reading from the cards, it's my opinion that the extra cost of the
high speed cards isn't worth it. But if you're going to be heavily
utilizing the cards, and/or writing to them frequently, the extra cost
may be justified. For the purpose I use my SD cards in my PDA, the
cost isn't really worth it, but given that I use a JumpDrive Trio with
these cards, as well as a camera, it's nice to have some high speed
cards.
Archived from groups: comp.sys.palmtops.pilot (More info?)
William P.N. Smith wrote in message news:<14s8b0dsfjt4abj1scve0078fern9tcoab@4ax.com>...
> Which of the above are "high speed" cards, and which Palm were the
> tests run on?
Archived from groups: comp.sys.palmtops.pilot (More info?)
On Fri, 21 May 2004 21:14:30 +0200, Erik Marchee
<Newz@no.spam.redshadow.demon.nl> was understood to have stated the
following:
>Does it make sence to buy high speed SD-cards for my Palm Tungsten|T?
I don't know if you're still reading this thread, but after examining
the results of the benchmarks I posted a few days ago, I decided to
reorganize my card usage. I can say without doubt, for my usage, it
makes a great deal of sense to use high speed cards.
You are about to answer a thread that has been inactive for more than 6 months. If you still wish to proceed, please ensure that your posting is original and does not duplicate or overlap any prior responses to this thread.