Moderator here. I'm not sure why you asked not to be pointed to support. It turns out there is an almost identical question (with the answer) posted in the support area e-Help. The Intel® e-Help desk is staffed by Intel representatives who support select Intel embedded platforms including Intel Atom™ and associated chipsets including US15W.
To access e-Help, you need to be a Privileged member of the Intel® Embedded Community.
If you are not already a Privileged member, you can request an upgrade to your community account here:
In addition to access to e-Help, Prvileged members may also access the confidential content within the Intel® Embedded Design Center, such as design documents, specifications, and training materials.
If you decide to take advantage of e-Help, you can find the relevant thread here:
Moderator here. I'm not sure why you asked not to be pointed to support.
Because these hints by you are only to make people feel stupid! I applied already for Priviledged membership before posting, because I am NOT stupid. Nevertheless I got no answer so far (after 1 week), and may never get the P.state this way, simply because I did have not cared so far to advertise the successful company on my web site, but instead focus on doing my best job as an engineer, as long as I get paid work.
It turns out there is an identical question (with the answer) posted in the support area e-Help.
Interesting - thanks for looking it up. Helpful? I still do not know. Saying "we know but we do not tell you" is a very bad habit, making people feel second class, or worse.
As said, I may never get access this way. Let's see, but not wait. Anyway, such info should be available to all interested developers. I NOW have the impression Intel did not learn that much after the famous FDIV Pentium bug, or learned, but forgot in the mean time. What a pity.
It may really be better to go with a FPGA as central component of an embedded design, or an ARM, just any environment with less information hiding.
I understand you on your own cannot give things out, but the best you can do is tell Management that there are developers which feel mis-treated. Thanks for forwarding that.
I had something similar with PCI Express. My application was streaming packets of irregular size to system memory. What really fixed up performance was modifying the DMA hardware in my FPGA to only write multiples of 64 bytes at a time (to be precise, for PCIe always right exactly max-payload-size, aligned to a 64-byte address boundary wherever possible) and leave my driver put the pieces back into individual packets.
The figures you mentioned were much the same as mine. From roughly 25 MB/s max I got up to 40 MB/s. The external source can't do any faster so I am currently satisfied. In fact I now have a total sustained load of about 80 MB/s on the Crownbeach system since everything I send to memory gets written back to a network drive for later analysis (my test setup-up for an industrial application)
By the way there is a statement on this somewhere in the IA manuals ( I think the one on optimisation) that I coincidently found after I had made the changes. Technical background has to do with caching on the FSB etc.
Questions?
