No performance difference between 1.5, 1.75 & 2GHz

Post Reply
JamesAb
Posts: 7
Joined: Mon Oct 31, 2016 8:56 pm
languages_spoken: english
ODROIDs: c2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by JamesAb »

Can anyone confim that 1130mV is in fact the maximum current possible?

I've tested 4 core 1896Mhz for Hi10 x264 anime (software decoded) and for the short time it worked (before freezing) it seemed to be the sweet spot for 1080p24Hz Hi10 x264 software decoding.

I guess that with a higher current active cooling would be mandatory but I think the convenience of 1080p Hi10 decoding capability more than offsets that requirement.

Edit: In my tests I found that 1752Mhz with DDR3 overclock is sufficient for some of my test cases (a small subset unfortunatelly).

User avatar
odroid
Site Admin
Posts: 34859
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 933 times
Been thanked: 760 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by odroid »

Right. 1130mV is the maximum output voltage from the DCDC converter.

tchiwam
Posts: 83
Joined: Wed Dec 30, 2015 4:53 am
languages_spoken: english, French, Finnish, Greenlandic(little)
ODROIDs: 5x XU4, 3x C2, 2 cloudshell, 1 VU7, 1 VU7+, UPS1, UPS2, UPS3, USB/SATA, and many other fine bits from Odroid
Location: Greenland
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by tchiwam »

You mean there's no way to tweak the DCDC, even component level ?

User avatar
odroid
Site Admin
Posts: 34859
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 933 times
Been thanked: 760 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by odroid »

100% PWM duty ratio makes 1130mV. There is no room to increase the voltage.
If you remove the DCDC converter and connect an external power supply, you can try(or fry your board) 1.8~1.9Ghz.

neoroph
Posts: 7
Joined: Tue Aug 30, 2016 5:49 am
languages_spoken: english, german
ODROIDs: 2*C2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by neoroph »

odroid wrote:And we must consider some compensation for C2 users. But we need to check what we can do first.

Please accept my sincere apologies for the mistake and kindly understand our situation.
So....any news on this part?

mad_ady
Posts: 8317
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 573 times
Been thanked: 434 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by mad_ady »

neoroph wrote:
odroid wrote:And we must consider some compensation for C2 users. But we need to check what we can do first.

Please accept my sincere apologies for the mistake and kindly understand our situation.
So....any news on this part?
Well, I think that the Hardkernel team worked very hard to fix this issue even if the hardware is not stable at 2GHz. In the end all users gained performance compared to when they bought the boards for free, so I don't think any compensation is needed - at least not from HK. Amlogic should have to answer for their deceptive marketing though...

emu_can
Posts: 24
Joined: Tue Sep 06, 2016 2:06 pm
languages_spoken: english
ODROIDs: Several C2 boards.
2 x C0, 2 x XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by emu_can »

@neoroph
What kinds of compensation do you want?
$2 cash refund?
or $2 discount coupon for the next C3 board?

@mad_ady
I agree. I'm very happy with 1.75Ghz cpu overclocking and 1104Mhz ram overclocking now.
But I guess most people may like to receive $2~3 discount coupon :D

tchiwam
Posts: 83
Joined: Wed Dec 30, 2015 4:53 am
languages_spoken: english, French, Finnish, Greenlandic(little)
ODROIDs: 5x XU4, 3x C2, 2 cloudshell, 1 VU7, 1 VU7+, UPS1, UPS2, UPS3, USB/SATA, and many other fine bits from Odroid
Location: Greenland
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by tchiwam »

2$ or 3$ coupon, or any other value :D

No thanks, Keep the money and make a better C3 or Xu5

I now Have 5 C2 and 5 Xu4, more are coming as I build that cluster of mine... All of them have tasks, One is tracking ADSB the other is a dual channel SDR analyser. Minecraft server, Kodi players and various number crunchers...

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

The math I did based on the missing 250Mhz prorated against my estimated cost of the S905 SoC (the rest of the board is unaffected), puts the value under $0.50 USD. The cost of postage to claim it would exceed this amount. So, I also do not think compensation is worth bothering with.

mad_ady
Posts: 8317
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 573 times
Been thanked: 434 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by mad_ady »

@crashoverride: it's missing 250MHz * 4 cores, so... 2$ :lol:

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

mad_ady wrote:@crashoverride: it's missing 250MHz * 4 cores, so... 2$ :lol:
and before we knew it was only 250 * 4 cores it was 500MHz * 4 cores :o im missing a core :lol:

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

mad_ady wrote:it's missing 250MHz * 4 cores, so... 2$
That did point out an error in my calculation. I made the same mistake. 4 cores does not yield 4X performance; therefore, there is even less value than I assigned. Lets call it $0.33 now. ;)

[edit]
Now that I think more about it. Once you pass the speed of the DRAM, the real world work you get out of the CPU diminishes as it spends more cycles stalled waiting on the memory bus...
So, I am going to further revise my estimate to $0.10 USD.

emu_can
Posts: 24
Joined: Tue Sep 06, 2016 2:06 pm
languages_spoken: english
ODROIDs: Several C2 boards.
2 x C0, 2 x XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by emu_can »

Quick search on the China IC markets, the S905 street price seems to be around $6.7~$7.7
Let's assume HK bought the S905 chip at $7. And how much we can expect?
I agree we can abandon $2 or $3. :D I hope HK keeps alive for a long time to supply nice linux toys for my hobby.

Edit: according to dramexchange.com, 2GByte DDR3 street price is around $10. :o so we can expect only $1 or $2 at maximum.
I gave up. :mrgreen:

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:
mad_ady wrote:it's missing 250MHz * 4 cores, so... 2$
That did point out an error in my calculation. I made the same mistake. 4 cores does not yield 4X performance; therefore, there is even less value than I assigned. Lets call it $0.33 now. ;)

[edit]
Now that I think more about it. Once you pass the speed of the DRAM, the real world work you get out of the CPU diminishes as it spends more cycles stalled waiting on the memory bus...
So, I am going to further revise my estimate to $0.10 USD.
This depends on how you use the C2, I spend all my time waiting on USB interrupts for my real uses at the moment so dont really care how how many cycles it uses in a certain timeframe.

I would rather seen any compensation put back into development by hard-kernel with support from amlogic. We could nominate some projects? I think they have tried hard to increase frequency and overclocking options, but I would love to see support in drivers for some of the options in the S905 that the odroid C2 is hardwired to do and have not yet been developed or documented.

mad_ady
Posts: 8317
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 573 times
Been thanked: 434 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by mad_ady »

Crypto anyone? :)

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

mad_ady wrote:Crypto anyone? :)
Only after improved usb drivers or ps2 emulation on the GPIO :) and if no usb then I need to find a decent way to get audio in.

Crypto would be nice but I dont suspect it will be overly fast compared with 4 x cpu and neon, although I would like to be proven wrong.

mad_ady
Posts: 8317
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, C4, N1, N2, H2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 573 times
Been thanked: 434 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by mad_ady »

+1 for improved USB drivers... Hopefully it fixes the USB webcam glitches I keep seeing...

Pepes
Posts: 99
Joined: Mon Feb 15, 2016 5:28 am
languages_spoken: Czech | English
ODROIDs: C2 and U2
Location: Prague
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by Pepes »

another +1 for improved USB drivers!

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

Since we are already off-topic, I have been investigating USB recently. Specifically, these two patches:
https://github.com/LibreELEC/linux-amlo ... afcf1e7db2
https://github.com/LibreELEC/linux-amlo ... 4160c2a43f

The affect of the latter patch on C1 (where it is not present), indicates that with webcams the issue is with isochronous transfers. This is further supported by the reports of issues with other isochronus devices on the forum.

My question is to anyone using/experimenting with the mainline kernel. Are the USB issues also present there? Mainline has a different DWC driver. If theirs works, then we should backport it.

neoroph
Posts: 7
Joined: Tue Aug 30, 2016 5:49 am
languages_spoken: english, german
ODROIDs: 2*C2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by neoroph »

mad_ady wrote:
neoroph wrote:
odroid wrote:And we must consider some compensation for C2 users. But we need to check what we can do first.
Please accept my sincere apologies for the mistake and kindly understand our situation.
So....any news on this part?
Well, I think that the Hardkernel team worked very hard to fix this issue even if the hardware is not stable at 2GHz. In the end all users gained performance compared to when they bought the boards for free, so I don't think any compensation is needed - at least not from HK. Amlogic should have to answer for their deceptive marketing though...
Fixing an already sold system, that's not working as it is advertised / intended, is a "requirement", not a "nice to have". That's the meaning of a contract. And have bought 2 C2 boards (before this issue went public in this forum), that are supposed to work at 2 GHz, and I have only one that works close to the specs and only with additional costs like active cooling, a ton of time that I have invested in getting these to run etc.

I have bought complete C2 boards, not AMLogic CPUs. And odroid already mentioned that it was their fault, that they did not test the CPU properly.
That also means it is not my case to sue AMLogic for mislabeling their CPU for compensation.

I absolutely understand the position of some of you that HK also got surprised by this. And I don't want to express a "hey, your fault, gimme money, cash", because that's not the case. And I don't want them to go broke in having to replace a ton of systems (like Intel had to do with the famous pentium bug).

But they offered to consider a compensation. And I'd like to ask if that is still the case.

There are many ways, how such a compensation could work fairly. (And I really understand if some people rather waive their claim, just to support HK. But a contract is a contract, and in such mislabeling cases the manufacturer is eligible, not the shop. There still exist laws that have to be fulfilled and mislabeling might void a contract in the worst case). A direct refund is difficult and requires a ton of logistics, so probably no. But there are other ways to compensate and HK could still earn money: like shipping vouchers that are usable in their shop - or usable in any shop. Give a little, take a little.

And this kind of compensation is not that unusual:
For example: pollin went out of stock when I ordered my first c2, so they had to cancel the order (I have ordered the first one in France after that). And because of that I got a free shipping from pollin for my next order, no questions asked. And I used this free shipment when I ordered the second c2 as soon as they had it restocked. And a ton of additional stuff. Nice and fair, spent even money there, got something back. And more important: I'm a returning customer.

But it is not on me to decide what hardkenel wants to do in this case. I just picked up on something that have offered all by themselves. And that got kind of forgotten over the time. And if no one complains, nothing happens - so this time I play l'enfant terrible.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

neoroph wrote:I have bought complete C2 boards, not AMLogic CPUs.
The ethernet is still 1Gbs. The HDMI is still 4k. The RAM is still 2GB (in fact, the RAM actually got faster!). The USB is still 480mbs. The SDIO/eMMC are also still their respective speeds. The CPU is one of many components and its value is defined by the price of the SoC (among many components contained). While some may consider it more valuable than others, the market price is the generally agreed upon worth. The A53 is a "budget" core, its worth is defined in pennies by ARM licensing.

[edit]
Ironically, it would be far more deserving of outrage if a codec was under spec. The video codecs are far more valuable than the CPU is. Just look at how much RPI charges for a MPEG2 ($3.00) and VC1 ($1.50) license which are included in the S905.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote: The affect of the latter patch on C1 (where it is not present), indicates that with webcams the issue is with isochronous transfers. This is further supported by the reports of issues with other isochronus devices on the forum.

My question is to anyone using/experimenting with the mainline kernel. Are the USB issues also present there? Mainline has a different DWC driver. If theirs works, then we should backport it.
I haven't had chance to test USB on new kernel as yet, last time I built the new kernel I left the USB by mistake. I did however attempt at one stage to use the DWC2 driver in the hardkernel source (not the amlogic version in the amlogic folder) as it has also been updated to some degree but hit some issues supplying power and seen the 4.x version was reported working.

I havent built a new version 4.x for some time now, ill built one up now to see how the USB compares. I wonder if I can get 4.8 reatime patch installed on it too?

neoroph
Posts: 7
Joined: Tue Aug 30, 2016 5:49 am
languages_spoken: english, german
ODROIDs: 2*C2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by neoroph »

crashoverride wrote: The ethernet is still 1Gbs. The HDMI is still 4k. The RAM is still 2GB (in fact, the RAM actually got faster!). The USB is still 480mbs. The SDIO/eMMC are also still their respective speeds. The CPU is one of many components and its value is defined by the price of the SoC (among many components contained).
Yes, that's true, but the fact remains, that my primary c2 system runs almost bareable at 1,5GHz, it runs just okay at 1,75GHz, it runs really ok at 1,896GHz but with slight instabilities. So I can expect, it would run just good if it would just meet the initial specs.
crashoverride wrote: Ironically, it would be far more deserving of outrage if a codec was under spec. The video codecs are far more valuable than the CPU is. Just look at how much RPI charges for a MPEG2 ($3.00) and VC1 ($1.50) license which are included in the S905.
I know about the codec issues :( But the codec has not been advertised - so there is no contract issue.

And the RAM got faster - by overclocking it.

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 59 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by memeka »

neoroph wrote:
mad_ady wrote:
neoroph wrote:
odroid wrote:And we must consider some compensation for C2 users. But we need to check what we can do first.
Please accept my sincere apologies for the mistake and kindly understand our situation.
So....any news on this part?
Well, I think that the Hardkernel team worked very hard to fix this issue even if the hardware is not stable at 2GHz. In the end all users gained performance compared to when they bought the boards for free, so I don't think any compensation is needed - at least not from HK. Amlogic should have to answer for their deceptive marketing though...
Fixing an already sold system, that's not working as it is advertised / intended, is a "requirement", not a "nice to have". That's the meaning of a contract. And have bought 2 C2 boards (before this issue went public in this forum), that are supposed to work at 2 GHz, and I have only one that works close to the specs and only with additional costs like active cooling, a ton of time that I have invested in getting these to run etc.

I have bought complete C2 boards, not AMLogic CPUs. And odroid already mentioned that it was their fault, that they did not test the CPU properly.
That also means it is not my case to sue AMLogic for mislabeling their CPU for compensation.

I absolutely understand the position of some of you that HK also got surprised by this. And I don't want to express a "hey, your fault, gimme money, cash", because that's not the case. And I don't want them to go broke in having to replace a ton of systems (like Intel had to do with the famous pentium bug).

But they offered to consider a compensation. And I'd like to ask if that is still the case.

There are many ways, how such a compensation could work fairly. (And I really understand if some people rather waive their claim, just to support HK. But a contract is a contract, and in such mislabeling cases the manufacturer is eligible, not the shop. There still exist laws that have to be fulfilled and mislabeling might void a contract in the worst case). A direct refund is difficult and requires a ton of logistics, so probably no. But there are other ways to compensate and HK could still earn money: like shipping vouchers that are usable in their shop - or usable in any shop. Give a little, take a little.

And this kind of compensation is not that unusual:
For example: pollin went out of stock when I ordered my first c2, so they had to cancel the order (I have ordered the first one in France after that). And because of that I got a free shipping from pollin for my next order, no questions asked. And I used this free shipment when I ordered the second c2 as soon as they had it restocked. And a ton of additional stuff. Nice and fair, spent even money there, got something back. And more important: I'm a returning customer.

But it is not on me to decide what hardkenel wants to do in this case. I just picked up on something that have offered all by themselves. And that got kind of forgotten over the time. And if no one complains, nothing happens - so this time I play l'enfant terrible.
The point is that this compensation is too small to be practical - 50 cents by some, but let's say it's 1$. No matter how you wanna do it, the compensation is worth nothing to the end user, but requires some logistics and time from HK, which is not a big company. I totally understand your point, and I agree with it, but as a returning customer I would like for HK to spend that time improving their software (e.g. Mainline kernel) or better designing their next board, than giving me 2$ back. Yours is a point of principle, mine of practicality.

neoroph
Posts: 7
Joined: Tue Aug 30, 2016 5:49 am
languages_spoken: english, german
ODROIDs: 2*C2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by neoroph »

memeka wrote: Yours is a point of principle, mine of practicality.
Experimenting with business ideas sometimes means, you have to act on principles, since you don't always have the luxury of practicality.
I'm totally fine if hardkernel states there won't be any compensation. Then you can compute certain risk factors.

But as of this point I have no statement saying that, I only have one that they are considering it, not mentioning how.

So I asked for an update.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote: My question is to anyone using/experimenting with the mainline kernel. Are the USB issues also present there? Mainline has a different DWC driver. If theirs works, then we should backport it.
"itop -a" shows the interrupts at 8000 per sec for USB..

Code: Select all

INT                NAME          RATE             MAX
  1 [   0          0   ]     0 Ints/s     (max:     0)
  2 [   0          0   ]     0 Ints/s     (max:     0)
  3 [7631      48510   ]     4 Ints/s     (max:    15)
  4 [   0          0   ]     0 Ints/s     (max:     0)
 10 [   0          0   ]     0 Ints/s     (max:     0)
 11 [   0          0   ]     0 Ints/s     (max:     0)
 17 [   0          0   ]  8006 Ints/s     (max:  8008)
 18 [   0          0   ]    10 Ints/s     (max:    48)
^C
odroid@odroid64:~$ cat /interupts
cat: /interupts: No such file or directory
odroid@odroid64:~$ cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
  1:          0          0          0          0     GICv2  25 Level     vgic
  2:          0          0          0          0     GICv2  29 Level     arch_timer
  3:      29948      20043      17682      48662     GICv2  30 Level     arch_timer
  4:          0          0          0          0     GICv2  27 Level     kvm guest timer
 10:          0          0          0          0     GICv2  53 Edge      c1108500.i2c
 11:        359          0          0          0     GICv2 225 Edge      meson_uart
 17:   27952108          0          0          0     GICv2  63 Level     c9100000.usb, dwc2_hsotg:usb1
 18:      16171          0          0          0     GICv2  40 Edge      eth0
IPI0:     31673      55431      29869      28011       Rescheduling interrupts
IPI1:        91        100         40         93       Function call interrupts
IPI2:         0          0          0          0       CPU stop interrupts
IPI3:         0          0          0          0       Timer broadcast interrupts
IPI4:         2          0          0          0       IRQ work interrupts
IPI5:         0          0          0          0       CPU wake-up interrupts
Err:          0
odroid@odroid64:~$ 
not sure the easiest way to test at the moment but I want to see if the interrupts are blocking.

philw38
Posts: 32
Joined: Thu Mar 10, 2016 4:53 am
languages_spoken: english
ODROIDs: C2, XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by philw38 »

brad wrote:
crashoverride wrote: "itop -a" shows the interrupts at 8000 per sec for USB..

Code: Select all

INT                NAME          RATE             MAX
  1 [   0          0   ]     0 Ints/s     (max:     0)
  2 [   0          0   ]     0 Ints/s     (max:     0)
  3 [7631      48510   ]     4 Ints/s     (max:    15)
  4 [   0          0   ]     0 Ints/s     (max:     0)
 10 [   0          0   ]     0 Ints/s     (max:     0)
 11 [   0          0   ]     0 Ints/s     (max:     0)
 17 [   0          0   ]  8006 Ints/s     (max:  8008)
 18 [   0          0   ]    10 Ints/s     (max:    48)
8000 interrupts per second matches the number of micro-frames / sec on a high speed (480MB/s) bus. That figure represents one interrupt each 125 microseconds (the USB micro-frame duration). Does anyone knows a mean to measure the cpu load it represents inside the kernel? Thx.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

philw38 wrote:Does anyone knows a mean to measure the cpu load it represents inside the kernel? Thx.
This thread is relevant to measuring of the interrupts http://forum.odroid.com/viewtopic.php?f=141&t=24229

This one to my issues with realtime kernel patches, the realtime performance and threaded IRQ with the USB host controller..
http://forum.odroid.com/viewtopic.php?f ... 2&start=50

Im now going to do some testing to see if there are conflicts on the new kernel. I figure the best way to test is to apply realtime patches & enable threaded IRQ. Then I can, 1) test cpu usage of the irq threads, and 2) see if they block other processes whilst timing the USB.

Edit: had trouble applying 4.8 rt patch to 4.9-rc2 (or wasn't very clean to try to compile) now 2nd option. Compile up jackd and run it against the 4.9 with various usb audio interfaces in duplex mode and low latency preempt. Check for xruns, stalls, crashes, pops, whistles.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:Since we are already off-topic, I have been investigating USB recently. Specifically, these two patches:
https://github.com/LibreELEC/linux-amlo ... afcf1e7db2
https://github.com/LibreELEC/linux-amlo ... 4160c2a43f

The affect of the latter patch on C1 (where it is not present), indicates that with webcams the issue is with isochronous transfers. This is further supported by the reports of issues with other isochronus devices on the forum.

My question is to anyone using/experimenting with the mainline kernel. Are the USB issues also present there? Mainline has a different DWC driver. If theirs works, then we should backport it.
OK im excited :D

Ive done some inconclusive testing and so far im impressed. I haven't installed realtime patches and enabled threaded IRQ as yet to measure, but I do have low latency audio in a round about way using multiple audio interfaces to capture and playback

- Standard 4.9 linux-next kernel with new USB support enabled, low latency desktop PREEMPT selected
- Cheap C-media guitar audio interface for capture plugged into c2 USB
- Hardkernel USB audio interface for playback plugged into c2 USB
- Storage and root filesystem via USB (emmc via sd card adptors)

I removed the Ubuntu jack libraries compiled supported aarch64 version, compiled guitarix, ran the GUI over X11 forwarding to my laptop and tested.

I cannot get any card to work in duplex mode, if I try I get instantaneous xruns (ie USB cannot keep up realtime). If I specify seperate USB devices for playback and capture it works well although the audio devices are connecting at USB 12Mbit..

Code: Select all

odroid@odroid64:~$ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 3, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 1: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 1: Dev 3, If 2, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 1: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 3: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
        |__ Port 3: Dev 5, If 3, Class=Human Interface Device, Driver=usbhid, 12M
Jackd has been working for hours running with realtime priority on low latency kernel with no problems, not even a hiss at boot or a pop at any stage and no xruns. Also it does not appear to hold up or block other processes. I have it running with an audio block latency of 5.3ms over 2 frames at 192000Hz giving a total jack latency of 11.6ms.

Code: Select all

odroid@odroid64:~$ jackd -v -r -P89 -p1024 -t1000 -dalsa -r192000 -n2 -P hw:0 -C hw:1
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in non-realtime mode
self-connect-mode is "Don't restrict self connect requests"
Jack: JackPosixThread::StartImp : create non RT thread
Jack: JackPosixThread::ThreadHandler : start
Jack: capture device hw:1
Jack: playback device hw:0
Jack: apparent rate = 192000
Jack: JackDriver::Open capture_driver_name = hw:1
Jack: JackDriver::Open playback_driver_name = hw:0
Jack: Check protocol client = 8 server = 8
Jack: JackEngine::ClientInternalOpen: name = system
Jack: JackEngine::AllocateRefNum ref = 0
Jack: JackPosixSemaphore::Allocate name = jack_sem.1000_default_system val = 0
Jack: JackEngine::NotifyAddClient: name = system
Jack: JackGraphManager::SetBufferSize size = 1024
Jack: JackConnectionManager::DirectConnect first: ref1 = 0 ref2 = 0
Jack: JackGraphManager::ConnectRefNum cur_index = 0 ref1 = 0 ref2 = 0
Jack: JackDriver::SetupDriverSync driver sem in flush mode
creating alsa driver ... hw:0|hw:1|1024|2|192000|0|0|nomon|swmeter|-|32bit
configuring for 192000Hz, period = 1024 frames (5.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 2 periods for playback
Jack: JackSocketServerChannel::Open
Finally root is mounted on USB storage also, I want to try a faster usb hard drive to see what throughput is possible.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote: The affect of the latter patch on C1 (where it is not present), indicates that with webcams the issue is with isochronous transfers. This is further supported by the reports of issues with other isochronus devices on the forum.
My testing so far with the devices I have has shown me that the issues with isochronoous transfers on the host controller are now contained within the actual device node for the newer DWC2 driver and kernel. I dont know if this is due to the updated kernel or updated USB drivers as yet but I plan to do some tracing to find out.

As this is software rather than a hardware USB controller, I think there is some room for improvement yet. It seems current controller tries to grab 2 streams of data to perform isochronoous transfers and using obscure spinlocks causes its own fate with conflict in the scheduler. In new kernel this conflict seems to limited to the device (rather than the entire host controller)

Edit: actually the entire kernel (and the interface to arm firmware) is conflicting with the USB in its current form, not just the 1 host controller. USB will hold up any process if the process is wanting to use CPU0 and a USB irq is spinlocked on it (including the other USB host if enabled.)

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

mad_ady wrote:Crypto anyone? :)
http://www.spinics.net/lists/arm-kernel/msg542079.html

arm crypto functions being optimised for sha2 and openssl, I do wonder the performance of the amlogic crypto though.

rowan194
Posts: 150
Joined: Tue Jun 02, 2015 1:43 am
languages_spoken: english
ODROIDs: C1, XU4, C2
Has thanked: 0
Been thanked: 3 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by rowan194 »

I've only just discovered this "issue" because an apt-get upgrade warned me that it replaced boot.ini, and I went in to see what had changed...

When I first got my C2 I benchmarked it against the C1, using a real world (ie not a synthetic test) CPU-bound application, compiled natively on each board:

Code: Select all

           raw val      index
C1      18.8Mops/s       1.00
C2      25.2Mops/s       1.34
Now here's where it gets interesting. If you scale the raw bench values by reported clock speed, 18.8 / 1.5GHz * 2GHz = 25.1. That's almost an exact fit to the measured value (25.2), even though the C2 was not actually running at the reported 2GHz clock speed.

I was expecting better performance per GHz when comparing the ARMv7 A5 to the ARMv8 A53, so I was a bit disappointed at the result - the measured results suggest the two CPUs are virtually identical when scaled for clock rate.

BUT it seems that instead of the A53 not being any better than the A5, it is a fair bit better, and that performance boost coupled with the numbers scaling perfectly masked the issue of the A53 not actually running at the reported clock speed!!!

Strange how these things happen...

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

Hello hardkernel,
Since the update to uboot / bootloader to support the higher CPU frequencies we have some issues using the newer upstream kernel 4.x

The current hardkernel kernel has a boot parameter to limit the cpu frequency at boot time which allows it to be set low enough to not cause the kernel to crash during boot.

The new upstream kernel does not have this feature and expects to be able to read and use valid DVFS frequencies from the OPP table from bootloader / u-boot and as a result cpufreq has been disabled in upstream due to crashes during boot when the cpu frequency hits high frequencies. See link below where cpufreq is disabled due to the issue...

https://git.kernel.org/cgit/linux/kerne ... 20f2d88e73

There are a few of us that would like to use cpufreq with a standard upstream kernel and to do this we need to use an old version of uboot/ BL2 limited to 1.5Ghz and re enable cpufreq in new kernel)

Would it be possible to produce an alternate version of uboot / BL2 with OPP table to support only up to 1.5Ghz? (For my purposes 1.7Ghz max would suit fine and allow me to boot)

Even better if the OPP table might be able to be updated within boot.ini file at boot dynamically without the need to pass a kenel parameter to the kernel to limit the maxfreq?

Thanks,
Brad.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

Im my opinion, the HardKernel method is the one that is valid. The OPP (operating performance point) of 2Ghz is real unlike other S905 platforms where its "fake" (1.5Ghz) and reported as 2Ghz which is the condition that prompted this thread to begin with.

It is necessary to have a "full" OPP table to support over-clocking and advanced scenarios such as 2Ghz but with a single core. Therefore, I submit that it is upstream that needs to add a "max cpu frequency" parameter as a kernel parameter or a device tree entry.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:Im my opinion, the HardKernel method is the one that is valid. The OPP (operating performance point) of 2Ghz is real unlike other S905 platforms where its "fake" (1.5Ghz) and reported as 2Ghz which is the condition that prompted this thread to begin with.

It is necessary to have a "full" OPP table to support over-clocking and advanced scenarios such as 2Ghz but with a single core. Therefore, I submit that it is upstream that needs to add a "max cpu frequency" parameter as a kernel parameter or a device tree entry.
Hi crashoveride,
I have some mixed opinions here and I tend to believe upstream kernel developers will frown upon OPP entries FOR DVFS which are not supported and must be restricted by a kernel parameter to be able to boot. ( I will look into restricting via DT entry this interesting)

I feel additional functionality needs to be enabled in the OPP table in the ATF to support overclocking or a turbo style mode for the the odroid c2 rather than standard OPP table entries being used which are invalid and not supported for S905.

There are kernel parameters to support single core startup, but the odroid C2 will not run at 2GHz even with 1 core (1 out of 10 times I can maybe boot without an illegal instruction error before it crashes shortly afterward with any type of CPU load)

As I cannot access the ATF source code in its current form, Im requesting some help from hardkernel to make the bootloader as compatible as possible before I attempt hacking the entries in the bootloader binaries for my purposes.

Thanks, Brad.
Last edited by brad on Sun Feb 19, 2017 9:43 am, edited 1 time in total.

User avatar
rooted
Posts: 7875
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 724 times
Been thanked: 222 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by rooted »

crashoverride wrote: Therefore, I submit that it is upstream that needs to add a "max cpu frequency" parameter as a kernel parameter or a device tree entry.

I agree but as you likely already know you can't easily get anything changed upstream once he/she/they set their minds to the way it should be done.

A valid argument goes a long way with some kernel developers though.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

In the long term, I do not think it matters whether mainstream includes a "patch" or not. Mainstream will need a vendor (HardKernel github) maintained branch just as we have today. RPi does this too. We will likely require it for Mali integration.

Someone should raise the issue with overclocking (out-of-spec OPP entries) to the BayLibre developer(s) on the mailing list. There may be other preferred methods of solving the issue.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:In the long term, I do not think it matters whether mainstream includes a "patch" or not. Mainstream will need a vendor (HardKernel github) maintained branch just as we have today. RPi does this too. We will likely require it for Mali integration.

Someone should raise the issue with overclocking (out-of-spec OPP entries) to the BayLibre developer(s) on the mailing list. There may be other preferred methods of solving the issue.
Thanks ill contact them to see what there thoughts are, but im aiming for full mainstream support without a need for a separate branch. Mali is being expanded in mainstream for gxbb at the moment so hopefully some support. Not that i need mali at all.

Edit: in regards to mali support, patches submitted to enable the devicetree node for mali https://patchwork.kernel.org/patch/9566377/

Driver support from mali-450 is still missing but the malidp drivers are constantly being worked upon.

I have now asked for opinions from the linux-amlogic kernel developers.

umiddelb
Posts: 452
Joined: Thu Jan 29, 2015 6:42 am
languages_spoken: English, German
ODROIDs: ODROID-C1, ODROID-XU4, ODROID-C2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by umiddelb »

brad wrote:[...]
There are a few of us that would like to use cpufreq with a standard upstream kernel and to do this we need to use an old version of uboot/ BL2 limited to 1.5Ghz and re enable cpufreq in new kernel)

Would it be possible to produce an alternate version of uboot / BL2 with OPP table to support only up to 1.5Ghz? (For my purposes 1.7Ghz max would suit fine and allow me to boot)

Even better if the OPP table might be able to be updated within boot.ini file at boot dynamically without the need to pass a kenel parameter to the kernel to limit the maxfreq?

Thanks,
Brad.
+1

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:Someone should raise the issue with overclocking (out-of-spec OPP entries) to the BayLibre developer(s) on the mailing list. There may be other preferred methods of solving the issue.
Its still in discussion with many different valid opinions from the linux-amlogic and other kernel developers / reviewers. I feel it is a choice of a workaround vs fixing the problem, ie invalid frequencies in the DVFS table provided by the firmware (not to say the firmware should not provide overclocking frequencies as well)

If it cant be done in the arm firmware (amlogic) for whatever reason, maybe it can be done by modifying Uboot to change the DVFS entries (Edit: I should mention via boot.ini without recompile) before booting the OS, at least thats a workaround that does not have to go to mainline kernel and still within the bootloader.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

brad wrote:Its still in discussion with many different valid opinions from the linux-amlogic and other kernel developers / reviewers.
I noticed the device tree approach is already proposed:
http://lists.infradead.org/pipermail/li ... 02317.html
[PATCH 2/2] cpufreq: scpi: RfC - Allow to ignore invalid SCPI DVFS clock rates

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:
brad wrote:Its still in discussion with many different valid opinions from the linux-amlogic and other kernel developers / reviewers.
I noticed the device tree approach is already proposed:
http://lists.infradead.org/pipermail/li ... 02317.html
[PATCH 2/2] cpufreq: scpi: RfC - Allow to ignore invalid SCPI DVFS clock rates
And still under much discussion about a fix or workaround...
http://lists.infradead.org/pipermail/li ... 02356.html

As to why im asking hardkernel for vendor support.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

I did read that before. However, the premise is flawed:

Sudeep Holla (ARM) is stating the firmware is "bad" and needs to be fixed. The reality is that its "by-design" and the additional OPP entries are not invalid. Neil Armstrong (BayLibre) states the issue is "due to a bad hardware design". However, the issue affects all S905/S912 and is not OEM specific.

SCPI is "System Control Processor Interface" defined by ARM. Presumably, it runs on the M3 core and not the A53 cores.
http://infocenter.arm.com/help/index.js ... IECBE.html

The proposed solutions are:
1) Remove "over clocking" OPPs entirely.
2) Bypass SCPI for C2 only.
3) Provide firmware for HardKernel maintained Linux and a separate one for mainstream Linux.
4) Modify the firmware to allow switching between HardKernel/mainstream Linux.
5) Add a kernel parameter or device tree entry to specify max operating frequency.

The only proposed solution that does not place additional burden on OEMs and end-users is the "parameter/device tree entry". Of these, the device tree makes the most sense. If the "max-frequency" is present, use it. If its not, then don't. It is trivial to modify the device tree in uboot (boot.ini) and is already done for other things. This means the Odroid C2 device tree can ship with "max-frequency" set to 1.5Ghz and boot.ini can change it. For other OEM boards, the device tree does not need to be changed. It also allows end-users to "under-clock" for harsh environments without having to maintain either their own firmware or kernel.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote:I did read that before. However, the premise is flawed:

Sudeep Holla (ARM) is stating the firmware is "bad" and needs to be fixed. The reality is that its "by-design" and the additional OPP entries are not invalid. Neil Armstrong (BayLibre) states the issue is "due to a bad hardware design". However, the issue affects all S905/S912 and is not OEM specific.

SCPI is "System Control Processor Interface" defined by ARM. Presumably, it runs on the M3 core and not the A53 cores.
http://infocenter.arm.com/help/index.js ... IECBE.html

The proposed solutions are:
1) Remove "over clocking" OPPs entirely.
2) Bypass SCPI for C2 only.
3) Provide firmware for HardKernel maintained Linux and a separate one for mainstream Linux.
4) Modify the firmware to allow switching between HardKernel/mainstream Linux.
5) Add a kernel parameter or device tree entry to specify max operating frequency.

The only proposed solution that does not place additional burden on OEMs and end-users is the "parameter/device tree entry". Of these, the device tree makes the most sense. If the "max-frequency" is present, use it. If its not, then don't. It is trivial to modify the device tree in uboot (boot.ini) and is already done for other things. This means the Odroid C2 device tree can ship with "max-frequency" set to 1.5Ghz and boot.ini can change it. For other OEM boards, the device tree does not need to be changed. It also allows end-users to "under-clock" for harsh environments without having to maintain either their own firmware or kernel.
This is all good and well crashoveride but for the C2 but you need to think about the logistics of making such a change and why we are actually here at this point.

1) amlogic the chip OEM advertised chips at 2GHz cores but only provided firmware to run them at 1.5GHz. I was ripped off and are disappointed. Hardkernel who license the the firmware for the chip are the C2 OEM and have some control over what the bootloaders can do.
2) users of mainline kernel run into the many many millions and I see Sudeep's point of view, in fact I think it is spot on.
3) It should not be a discussion about how to make an OS work with firmware but how to make firmware work with OS's. I would hate to have this same silly discussion if I were trying to get BSD to boot.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

brad wrote:I would hate to have this same silly discussion if I were trying to get BSD to boot.
I agree with that and its an excellent example. Its brings up a point that I have avoided stating until now: The heart of the issue lies in the ARM controlled SCPI specification. There is no way to express "performance" OPP entries. A new revision of SCPI is needed that allows for "extended" OPP entries above "default".

It seemed a more obtainable goal to add "max-frequency" to Linux than to ask ARM to update their specification and for OEMs to implement it.

[edit]
An example is XMP for DRAM:
https://en.wikipedia.org/wiki/Serial_pr ... detect#XMP
It allows for "extended" performance information to be specified.

User avatar
odroid
Site Admin
Posts: 34859
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean, Japanese
ODROIDs: ODROID
Has thanked: 933 times
Been thanked: 760 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by odroid »

I don't know what we should do at this moment.
Do you guys need a new boot blob which has a core clock table limited at 1.5Ghz to run the mainline kernel?

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

odroid wrote:I don't know what we should do at this moment.
Do you guys need a new boot blob which has a core clock table limited at 1.5Ghz to run the mainline kernel?
That might one solution, but it would prevent the ability to over-clock completely I believe? DVFS tables used to be set within the BL301 source which has moved into the blob I guess for ease of use.

https://github.com/hardkernel/u-boot/co ... 97183c7L34

I was hoping some calls could be made in uboot code (with help of boot.ini parameter) to communicate with the firmware and either add or remove DVFS entries for core clock rather than setting a parameter for the OS to do it.
Last edited by brad on Tue Feb 21, 2017 7:02 pm, edited 1 time in total.

brad
Posts: 1159
Joined: Tue Mar 29, 2016 1:22 pm
languages_spoken: english
ODROIDs: C2 N1 N2 N2+ H2 H2+ (64 bit ftw)
Location: Australia
Has thanked: 58 times
Been thanked: 105 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by brad »

crashoverride wrote: It seemed a more obtainable goal to add "max-frequency" to Linux than to ask ARM to update their specification and for OEMs to implement it.

[edit]
An example is XMP for DRAM:
https://en.wikipedia.org/wiki/Serial_pr ... detect#XMP
It allows for "extended" performance information to be specified.
It would be ideal, but I do agree it does not seem to be an achievable goal for the C2.

umiddelb
Posts: 452
Joined: Thu Jan 29, 2015 6:42 am
languages_spoken: English, German
ODROIDs: ODROID-C1, ODROID-XU4, ODROID-C2
Has thanked: 0
Been thanked: 0
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by umiddelb »

brad wrote:[...]

I was hoping some calls could be made in uboot code (with help of boot.ini parameter) to communicate with the firmware and either add or remove DVFS entries for core clock rather than setting a parameter for the OS to do it.
May be with the help of some black magic similar to this one here and here.

crashoverride
Posts: 5027
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 323 times
Contact:

Re: No performance difference between 1.5, 1.75 & 2GHz

Post by crashoverride »

The constraints are that:
1) SCPI runs on the M3, not A53 cores. (https://github.com/hardkernel/u-boot_fi ... le#L17-L18)
2) The M3 firmware is part of the boot loader chain (BL301). This is before "uboot" is in place.

The boot loader chain is "trusted" (Arm trusted firmware) so it can not be trivially replaced or altered dynamically at run-time. This implies at a minimum there will need to be an "extended" vendor command (see above SCPI link) added to the SCPI firmware to support mutliple DVFS tables (stock, over-clocking).

As noted before, HardKernel will likely need to maintain their own 4.x kernel branch. "max_frequency" can be added to that along with any other out-of-tree patches such as for Mali, the DAC board, etc. It, therefore, seems that what is needed is an interim solution until either mainstream adds "max_frequency" or HardKernel releases their 4.x branch.

I propose that this interim solution should be adding #ifdef's (config) to the uboot source code. This would allow a configuration switch that will build either stock or over-clock enabled boot firmware. Anyone using mainline is already accustomed to compiling/configuration. Adding uboot as a one time build requirement does not seem to be an undue burden.

[edit]
To clarify, HardKernel would continue to supply the boot loader as it is today. Those wishing "stock" DVFS can configure and build uboot without over-clocking tables by altering the config file.

Post Reply

Return to “Issues”

Who is online

Users browsing this forum: No registered users and 1 guest