download speed problem

download speed problem

[Yi Qingliang]

did you have done speed limit for the yocto source server recently?
I can only get < 10KBps :(


-- 
Nanjing Jilong
Yi Qingliang
niqingliang2003@gmail.com

Re: download speed problem

[Li.Wang]

You can download from foreign server, and then copy it to local.
But, you must have foreign server.

LiWang.

On 01/18/2013 11:07 PM, Yi Qingliang wrote:
> did you have done speed limit for the yocto source server recently?
> I can only get < 10KBps :(
>
>

OpenMP and OE-core (or: Why is OpenMP explicitly disabled?)

[Mike Looijmans]

Hello,

When trying to use OpenMP in an embedded ARM project, I found that 
oe-core explicitly tells GCC to NOT include the OpenMP support.

Is there a particular reason why this was done?

As an experiment, I just removed the "--disable-libgomp" OECONF 
additions from the GCC recipes, and added libgomp unconditionally (why 
is that only included for powerpc?).

Since multicore systems are getting more and more common even in 
embedded systems, I guess I shouldn't be the only one who bumped into this.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

Re: OpenMP and OE-core (or: Why is OpenMP explicitly disabled?)

[Burton, Ross]

On 18 January 2013 10:27, Mike Looijmans <mike.looijmans@topic.nl> wrote:
> When trying to use OpenMP in an embedded ARM project, I found that oe-core
> explicitly tells GCC to NOT include the OpenMP support.
>
> Is there a particular reason why this was done?

Mainly because multi-core historically isn't where OE is used, but
that's obviously changing as "embedded" is including massively
parallel data centre uses.

It's totally reasonable for this to be some sort of tunable you can
configure in local.conf, be it a gcc configuration you can override or
a DISTRO_FEATURE.

Ross

Re: OpenMP and OE-core (or: Why is OpenMP explicitly disabled?)

[Burton, Ross]

[re-adding oe-core to CC]

On 18 January 2013 10:58, Mike Looijmans <mike.looijmans@topic.nl> wrote:
> I'd welcome suggestions, especially for "words" to use. I'd be tempted to
> add "openmp" to MACHINE_FEATURES (because it's mostly a machine thing, I'd
> expect).
>
> Just compiling without the "--disable-libgomp" should be harmless
> regardless. Right?

If all that does is make the compiler larger, and doesn't impact
generated images, then you can make a case for enabling it always.

Ross

Re: OpenMP and OE-core (or: Why is OpenMP explicitly disabled?)

[Mike Looijmans]

On 01/18/2013 11:27 AM, Mike Looijmans wrote:
> Hello,
>
> When trying to use OpenMP in an embedded ARM project, I found that 
> oe-core explicitly tells GCC to NOT include the OpenMP support.
>
> Is there a particular reason why this was done?
>
> As an experiment, I just removed the "--disable-libgomp" OECONF 
> additions from the GCC recipes, and added libgomp unconditionally (why 
> is that only included for powerpc?).
>
> Since multicore systems are getting more and more common even in 
> embedded systems, I guess I shouldn't be the only one who bumped into 
> this.

I tested with simply compiling like that, and adding a 
"ac_cv_prog_c_openmp=-fopenmp" to the OECONF options because otherwise 
autotools tries to run an ARM binary on the build machine. The resulting 
image rusn fine, and my program get double the performance.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

Re: OpenMP and OE-core (or: Why is OpenMP explicitly disabled?)

[Mike Looijmans]

On 01/18/2013 12:02 PM, Mike Looijmans wrote:
> On 01/18/2013 11:27 AM, Mike Looijmans wrote:
>> Hello,
>>
>> When trying to use OpenMP in an embedded ARM project, I found that 
>> oe-core explicitly tells GCC to NOT include the OpenMP support.
>>
>> Is there a particular reason why this was done?
>>
>> As an experiment, I just removed the "--disable-libgomp" OECONF 
>> additions from the GCC recipes, and added libgomp unconditionally 
>> (why is that only included for powerpc?).
>>
>> Since multicore systems are getting more and more common even in 
>> embedded systems, I guess I shouldn't be the only one who bumped into 
>> this.
>
> I tested with simply compiling like that, and adding a 
> "ac_cv_prog_c_openmp=-fopenmp" to the OECONF options because otherwise 
> autotools tries to run an ARM binary on the build machine. The 
> resulting image rusn fine, and my program get double the performance.

The logical thing to do seems to me:

- Enable openmp for all platforms. This should be unconditionally, if 
you're building for multiple targets, some may have multiple cores and 
some don't, but they will share the compiler. The option will make the 
compiler bigger, but will not have any effect on the produced binaries 
(except when they ask for it). I have a GIT patch that does just that.

- Add some switch (is MACHINE_FEATURE a good place for that?) to enable 
openmp options. This should conditionally add 
"ac_cv_prog_c_openmp=-fopenmp" or "ac_cv_prog_c_openmp=unsupported" to 
the autotools options. Looks like it should go into the "site" files, 
but I don't have a clue as to how that can be accomplished conditionally.




Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.