Very slow internal A200 SATA controller and HDD operation!

[leschouk]

Hi guys!
From the first happy day of own the A200 NMT I noticed its very slow file operating system performance.
Before opening the new thread, I carefully looked trough the forum re the issue. I found several threads stated slow data transferring rates:
Slow disk/file operations
Slow data transfer rates
IDE hard drives too slow
Those threads also declare slow file operation but in one case the USB drive was involved, in the other the network speed could cause the issue.
I decided to make a pure experiment and I would like to discuss the results with you.
I needed to exclude all the factors that could interfere with file read/write operations.
Thus, I will use ONLY INTERNAL HDD for the experiment.
• I used a half-empty 1TB SATA Hard Drive ST31000520AS Seagate Barracuda LP (5900RPM), PIO 0-4;Multiword DMA 0-2;UDMA 0-6, formatted in EXT3, with NMT applications installed on it.
• I prepared a big 18 GB .mkv file on my INTERNAL HDD. To exclude fragmentation I recopied this file to the other folder of the same HDD using NMT file mode menu.
• I stopped all the NMT applications from the menu.
• I switched off the NMT Ethernet port.
• I went to the NMT file mode and added the selected file to the list. Then I went to the other folder of the same HDD and chose “Copy selected items here”. I started the timer and got the following results: 5,8MB/s (megabytes per second)! This was very slow for this UDMA6 SATA drive!
• I deleted the original copy of the file by pressing "delete" and "OK" buttons. The process of deleting took more than a minute! For some files it could be up to 5 minutes! This is extremely weird!
• Then I stopped the NMT and remount this drive into my PC: 3Ghz Pentium D 4GB RAM with UDMA6 SATA controller (Intel 945p, 82801G ICH7 ULTRA ATA), Windows XP Pro SP3 and EXT3 driver installed.
• I start copying the same file into its previous folder using Windows interface and made the measurements. The speed was 19,5MB/s. It was tipple as more as in the previous test!
I understand that this test did not show up a real transfer rate of the system and could even have slightly different results depending on file size, disk fragmentation, etc. Nevertheless, it is a good qualitative model to think over its results.
Let me speculate about the facts discovered before I ask your advice.
In this test, we can neglect the influence of the HDD internal speed characteristics.
The main things are system data processing speed and HDD external interface speed.
The system data processing speed for read/write operations depends on CPU and RAM performance as well as on algorithms used for these tasks. I suppose that Linux and Windows XP with EXT3 driver has common rate read/write operation performance. Please correct me if I am wrong! CPU and RAM capacities are not so important since most systems use DMA for disk operations.
I think that the bottleneck of this process is SATA controller, which set the speed mode of the HDD interface.
Fortunately, in Windows you can use plenty of utilities to determine SATA and UDMA modes as well as real HDD read/write speeds. Yet, Linux is not the same!
• Can someone propose the way to determine the operating mode of HDD SATA controller inside the NMT? Is it UDMA6 or PIO0 mode?
• Is there any way to switch HDD modes?
• Does anyone know any utility to measure NMT disk-into-memory data transfer speed?
I think the issue is important for many users. When I have NMT apps started the BD images (even not fragmented) become unwatchable after 30Mb/s. When everything switched off the video could stutter at the 100Mb/s peaks (Planet Earth, birds)

My hypothesis is that the NMT SATA controller does not provide the required HDD data transfer speed! It could be result of:
• a firmware bug;
• functional limitation of SATA controller used;
• HDD and SATA controller incompatibility;
• bad HDD Linux driver;
• no DMA protocols supported;
• bad cache and transfer algorithms used;
• whatever else

Please correct my false assumptions above if any.
I ask all the experts who have any suggestions to take part in this discussion.

[halfelite]

there is actual a few things going on remember disc io takes some cpu power and there is no cache ability like a computer might use. the cpu in the 200 series is 700mhz so a disc transfer takes kinda a big toll on the cpu doing read/write at the same time. using USB/network just add to it as a lot of them could share the same bus. Then you are limited by bus/cpu/controller.

Comparing it to a pc is bad analogy. Comparing it to something like a cell phone, dvd player, or a computer with a 700mhz cpu is a closer example

[leschouk]

(09-09-2010 02:11 AM)halfelite Wrote:  there is actual a few things going on remember disc io takes some cpu power and there is no cache ability like a computer might use. the cpu in the 200 series is 700mhz so a disc transfer takes kinda a big toll on the cpu doing read/write at the same time. using USB/network just add to it as a lot of them could share the same bus. Then you are limited by bus/cpu/controller.

Comparing it to a pc is bad analogy. Comparing it to something like a cell phone, dvd player, or a computer with a 700mhz cpu is a closer example

OK.
Can someone compare this operation with Dune NMT. It has almost the same hardware. But, it seems to me there is more sense to explore A200 SATA controller data sheet and check its operation mode and performance. Does someone know the utility that could give any info about SATA controller type and its UDMA mode?

[halfelite]

what speeds do you think you should be getting, this is an embedded system its not built for speed. You have a sata host connected to the phy connect to the cpu core. doing a read/write at the same time is considered heavy usage on this type of machine.

Quote:There is an internal general purpose 32-bit bus (GBus - how clever) that interconnects all the cores at least for control functions. Each core maps it's register file into different ranges of the GBus address space. And each ramdac maps physical ram into GBus address space as well. I'm not entirely clear on what performs bus arbitration or how exactly it's clocked, but it seems to be asynchronous. Even though each ramdac maps physical ram into a gbus address window, most high speed memory access travels through a number of dedicated hardware channels between each ramdac and each DSP and each DMA controller. SATA, for example, uses one of the general purpose DMA engines to move blocks from disk to memory through one of those back channels. Thus most of the high impact traffic is isolated off of it. However both the Ethernet MACs and the USB host controllers perform their own bus-mastering across GBus to/from preallocated memory pools - then throw completion interrupts to the host CPU

Here is a little on how the system works.

[leschouk]

(09-22-2010 09:35 PM)halfelite Wrote:  what speeds do you think you should be getting...

Well, of course the main thing is to avoid video stuttering during playback. When all other interfaces are off, I still have slight stuttering at 100 mb/s picks with defragmented “Ducks take off” 1080p test video file. I think that it is slow HDD to memory interface causes the issue. As soon as I add any other system routine (torrent, etc) the stuttering become unacceptable. This means that the HDD to RAMDAC speed is “at the edge”.
I do not know any objective method/utility for measuring HDD to RAMDAC speed. Could you advise any?

(09-22-2010 09:35 PM)halfelite Wrote:  SATA, for example, uses one of the general purpose DMA engines to move blocks from disk to memory through one of those back channels. Thus most of the high impact traffic is isolated off of it...

It sounds like a guess not real knowledge (sorry, I don't know whom you quoted). As soon as SATA occupies “one of” separate DMA channel it would be a good thing to double it bandwidth if it possible by registry mapping. Maybe some kind of data stream buffering could also help. Could you please address this question directly to Syabas hardware designers?

[Willem53]

start here http://www.sigmadesigns.com/uploads/docu...640_br.pdf

[halfelite]

(09-23-2010 07:58 PM)leschouk Wrote:  Well, of course the main thing is to avoid video stuttering during playback. When all other interfaces are off, I still have slight stuttering at 100 mb/s picks with defragmented “Ducks take off” 1080p test video file. I think that it is slow HDD to memory interface causes the issue. As soon as I add any other system routine (torrent, etc) the stuttering become unacceptable. This means that the HDD to RAMDAC speed is “at the edge”.
I do not know any objective method/utility for measuring HDD to RAMDAC speed. Could you advise any?

(09-22-2010 09:35 PM)halfelite Wrote:  SATA, for example, uses one of the general purpose DMA engines to move blocks from disk to memory through one of those back channels. Thus most of the high impact traffic is isolated off of it...

It sounds like a guess not real knowledge (sorry, I don't know whom you quoted). As soon as SATA occupies “one of” separate DMA channel it would be a good thing to double it bandwidth if it possible by registry mapping. Maybe some kind of data stream buffering could also help. Could you please address this question directly to Syabas hardware designers?

Have you tried a different drive as a test, as i tested 90mbit birds and it played just fine with no stutter. And i can assure you of how it works is real knowledge he might not know all the specifics of the pch but he has worked with the sigma chips long enough to know how they function. Also why are you trying to play 100mbit files that is way over the standard for blu-ray

[leschouk]

(09-24-2010 06:25 AM)halfelite Wrote:  Have you tried a different drive as a test, as i tested 90mbit birds and it played just fine with no stutter. And i can assure you of how it works is real knowledge he might not know all the specifics of the pch but he has worked with the sigma chips long enough to know how they function. Also why are you trying to play 100mbit files that is way over the standard for blu-ray

I tested my NMT by playing back “birds” because it shows the borders of system stability and bandwidth. I like to watch inmpessive high-bitrate videos (Planet Earth, Birds of Passage, etc.) As soon as PCH A200 is not a simple player it should perform several simple tasks simultaneously. I faced the fact that disk operations are very slow and the system incapable to perform smooth BD playback together with other task that takes any disk or CPU activity. Thus I believe developers could improve system stability and performance if they are able to increase HDD data bandwidth.
I didn’t test another drive, but I tested this particular drive in other environment and the speed was 3 times faster. I will take a USB 1TB drive for test soon.