Quite a bit for you to read!

[CommanderB]

If an upgrade will be cheap enough for the people who take the slower variant, I don´t care. Like a coupon, that enables everyone with the flawed CPU-Board to upgrade for the manufacturing price of an flawless board, if they so desire.

I think that this is a good approach, however the manufacturing costs would not be enough. The work hours for changing the CPU boards and the shipping must also be covered

Gesendet von meinem SM-N9005 mit Tapatalk

 

[der_gabe]

Couldn't you sell Pyras with the existing CPU boards at a discount? Why only sell them as keychains?
As I understand it, they have somewhat degraded SD card performance, but are otherwise perfectly functional. I'm sure there are people here who won't care about that and will gladly accept that limitation if it means getting their Pyra at a slightly lower price.
Maybe the 1000+ preorderers could be asked if they'd be willing to go that route. It just needs to be advertised clearly.
This way, ED could not only avoid loss but even make some profit on these CPU boards.

 

[zmatt]

Well the original plan was just having a switch to select between one or the other.

A switch would still be controlling a mux, so there's no benefit.

Does the mux bottleneck the speed by 50% of the original speed or by a maximum bandwidth the muxer allows? Because that would mean the eMMC would go down to 48 MB/s too... right?

If it were that simple, the number would have been there in my overview
[doublepost=1490275389,1490275193][/doublepost]

If it's switch vs muxer, speed vs ease of use, I think I'd rather wait for a board without the muxer

No muxer = no μSD slot.

 

[vcoleiro1]

As I mentioned before, since only 570 pcb's out the current 1032 pre-orders have been made. And since a number of people have said they don't mind getting the board with the emmc issue. My suggestion is to ask via email all the pre-orderers if they are willing to take one of the 570 boards with the isue. Fix the issue for the next batch made for the remaining pre-orders ie the ones that refuse the board with the emmc issue.

If less than 570 pre-orders accept the pcb board with the issue, then throw the rest out or sell them as souvenirs. I'm guessing out of the 1032 current pre-orders , that there will be 570 people that accept the pcb with the emmc issue. Perhaps offer a carrot for them if they accept, like getting it ahead of the others or something.

 

[klapse]

Or charge 7.26 euro more for each pyra to recoup the 7500 costs.

 

[der_gabe]

[...] Perhaps offer a carrot for them if they accept, like getting it ahead of the others or something.

Exactly. Or a slight discount...

 

[TrashyMG]

Or charge 7.26 euro more for each pyra to recoup the 7500 costs.

I wouldn't mind that either it's small enough of a bump I could stomach it. Also ED could also sell the CPU boards on top of that as well so maybe it doesn't have to be so much of a bump or have to sell so many key chains...

Also honestly I don't see myself using the uSD much so I woundn't mind just taking the boards as is... I guess it's up to ED to decide.

 

[pmprog]

Also honestly I don't see myself using the uSD much so I woundn't mind just taking the boards as is... I guess it's up to ED to decide

Surely then for you, the board would be least favourable to you? As it makes no difference to a user who only uses a uSD card, but slows the eMMC (which you'll be using)

 

[TrashyMG]

@pmprog, Okay then ED post is confusing me then...

 

[sm0kew0n]

@TrashyMG confusing you! Then I'm totally lost.

 

[PowerGod]

@pmprog, Okay then ED post is confusing me then...

I feel you

 

[CFWhitman]

I think that ED's original post says "SD card" where he meant to say "eMMC" here:

By using that switch, we've accidentally crippled the SD Card speed (which was certainly not what we planned

 

[Bokkertoff]

Just as a matter of interest. Look at the boot times for the various bus types and speeds.

For random IO (which is mostly what we do), it wont matter that much, but for the guys wanting it to copy large multimedia files, it will be a big deal.

The whole article is as http://www.overclock.net/t/1489684/ssd-interface-comparison-pci-express-vs-sata


It would be great if someone with a prototype can PLEASE give us the actual figures they get from reading and writing a 10GB file with dd. (Edit. using bs=1M)

 

[pmprog]

I think that ED's original post says "SD card" where he meant to say "eMMC" here:

This^
I don't see how the faster thing would cripple the slower thing, it's usually the other way around, so I suspect it was a mistype in his post.

This quote from zmatt seems to confirm that thought

so it's possible that fixing the speed for eMMC means sacrificing μSD

 

[Swordfish II]

Note that I don't even know if a suitable mux that doesn't have the same problem exists at all, so it's possible that fixing the speed for eMMC means sacrificing μSD.

This is the real key to all of this:

1. Does a faster Mux exist
2. If not, would people prefer
-Slower speeds and both micro and emmc
-Only emmc at a faster speed

I would take the slower speed to also have the microsd

 

[Silent-Hunter]

I'm certainly willing to take one of the current CPU boards. I don't even think it's going to be a problem.

 

[slaeshjag]

This is the real key to all of this:

1. Does a faster Mux exist
2. If not, would people prefer
-Slower speeds and both micro and emmc
-Only emmc at a faster speed

I would take the slower speed to also have the microsd

Depending on how tight space is, it might be do-able to put the µSD on a USB interface in a future CPU board revision. It would require a different USB-hub on the CPU board, as the current one has all lines used.

 

[Grench]

It kind of is. We were promised eMMC speeds, that was literally a key debate point early on in development: pros and cons of internal SD vs eMMC were presented and we were eventually told we could have both. Now we find out we can't have both, that the microSD camp has won by default: we have expandability at the expense of speed.

The transfer stats everyone is pointing to are theoretical maximum at the bus/slot. The individual component for the eMMC and the individual card for the microSD can never get -faster- than those numbers, but reality is that they will be slower - possibly MUCH slower - as in 20-50% of maximum theoretical - than the port bandwidth.

Depending on the eMMC part ordered, there may well be microSD cards available that will wind up being FASTER than the eMMC part. There are now microSD cards that can pretty much saturate the microSD slot's maximum bandwidth.
https://havecamerawilltravel.com/photographer/fastest-microsd-cards

Exactly which eMMC part is being used? Do we know? Is the eMMC part capable of random reads & writes at faster than 80MB/s? Yes, the board interface should theoretically be faster - but is the PART faster?

It doesn't matter whether it will be "fast enough" or not, this is a crippling design flaw and it needs to be spun properly. This isn't like on the Pandora with people complaining about "slow" SD writes because they don't understand the technology: this time around, people complaining about slow eMMC will be correct; it is transferring slower than it should, history shows that it was intended to be faster but due to this unforeseen flaw it can't.

Again, everything we're seeing is talking about maximum interface bandwidth. What is the claimed throughput of the actual eMMC part being used? Most of the ones available inside the OMAP5432 interface spec are considerably slower than the interface.

What I don't get is why the MUXer would cause this. My experience with such chips is that it's basically just a switch: two sets of X pins in, one set of X pins out, set the mux pin high and it selects one, set it low and it selects the other, and the signals pass from one input to the output unmodified. What is this one doing that's different and causes it to go at half speed? It almost sounds like it's a factor of the OMAP itself locking the speed, and if that's the case maybe it can be selectable at boot time and just have one or the other as originally desired instead of being able to flip flop between them at run time.

Although I would love to have this flip/flop mechanism work and have access to both eMMC and microSD during the same session, I'm actually OK with the concept of only having the choice available at boot.

As long as it's faster than an SD card I don't care

You have no idea what the latest V30 generation of microSDXC cards are capable of. They're freekin' fast. Like 1st generation SSD fast. Like 500% faster than the Pandora's SDXC slots. That they run on a bus only capable of 1/2 the theoretical speed of the eMMC isn't really that big of a knock.

 

[slaeshjag]

The eMMC used in the pyra can in theory easily exceed what any microSD could do on the same interface, in both read and write speed. Rated figures are something insane like 270 MB/s read, 140 MB/s write. Those read speeds are better than what the OMAP5 eMMC interface supports.

 

[Grench]

You probably know that we've got an internal MicroSD Card slot and the eMMC and you can either use (or boot) from one or the other.
So far so good, we're using a switch (MUXer) for that. The switch supports SD Cards up to 96Mbps (should be UHS-3) - however, the eMMC would be able to run with up to 192Mbps (so about twice as fast).
And that's the problem: By using that switch, we've accidentally crippled the SD Card speed (which was certainly not what we planned) - and as that switch is on the CPU Board where 570 have already been produced, it's not easy to fix that.

What does that mean? Well, in theory, the read speeds of the eMMC on our CPU board would be quite a bit slower than it should.
However, how much slower is something we still need to test (we're working on that. Nikolaus is also modifiying one CPU board so we can test the speed without the switch as well).

Does that even have an effect in reality?
That's something we still need to test (we only found out about that yesterday, so we haven't finished all tests).

Some information here...

1. Linux doesn't access the eMMC that often. We're not using Windows here (which accesses the harddisk all of the time), but Linux. And Linux usually has very little disk access. Once it has booted up, it doesn't need to load a lot of stuff. In fact, the only things I can think of where fast read/write rates would be important would be a swap file... and that shouldn't be on an eMMC anyways.
2. Even if programs have high disk access, it could very well be the CPU is a limiting factor. If a program needs some time to analyze or unpack the data it loads, it wouldn't load things faster, even if the storage would be a lot faster.
3. It's also unknown whether the theoretical speed would be reachable anyways. I've often seen "Speeds up to xxx" whereas in reality, it was a lot slower.
4. It's still a multiple times faster than the Pandora and could reach speeds only UHS-2 and UHS-3 SD Cards support. So "slow" isn't really "slow" here.

So too early to make final decisions yet, but of course I'll let you know more after the tests.
If there's no other limiting factor (like the CPU, etc.), then the difference when loading a 100MB/s file would be a loading time of approx. 1,2s compared to 0,6 - 0,7s.
If the program that needs the data can't handle it that fast, the difference will be even less.

I'm a bit confused on this. I'm really looking forward to more information about the topic.

Is the MUXer slowing down the eMMC or the microSD or both?

Is the slowing down only happening while using the MUXer to operate both ports at once? i.e. if it is locked to one or the other, do they still get full bandwidth?

If the MUXer and the eMMC went away, would the microSD port be able to run at full speed? If so, what could it squeeze out of one of the latest generation UHS-I V30 cards?
Example:

https://www.amazon.com/SanDisk-Extreme-microSDHC-Adapter-SDSQXVF-032G-GN6MA/dp/B01HU3Q6F2

If the MUXer and the microSD went away, would the eMMC port be able to run at full speed? If so, what could it squeeze out of the chosen eMMC part? What part has been chosen for the eMMC?

When available, can we get some numbers around how fast is slow? I.e. in the current setup, how badly does it impact the throughput for eMMC and/or microSD?

Personally, I would prefer to max out the microSD speed even if that means that the eMMC gets "throttled" to microSD speeds.

I am very excited to see the project moving forward!