[FOSS-GPS] RTKLib MIPS requirements?

Thu May 3 08:45:45 EDT 2012

I remember seeing that a long time ago, but forgot about it.  Hmm, it 
does have useful figures.

The A8 at 600MHz would be capable of 1200 DMIPS.  At 20% utilization for 
10Hz GPS operation that would indicate 240 DMIPS used, and that's with 
the TMS320C64x DSP.  However, AFAIK that's not a floating-point DSP core 
and I expect you'd have to do a lot of tinkering with the compiler to 
get it to send any math to the DSP core.  I suspect it wasn't used.  The 
article doesn't mention the TMS320C64x DSP except in the Beagle specs.

The STM32F4 is capable of 210 DMIPs.  Hmm, that's troubling.  There's 
still overhead which hasn't even come into play yet.  I would expect 
compiling to metal would be substantially more efficient but I don't 
KNOW that.  Then again, it doesn't HAVE to be 10Hz, we could go with 5Hz 
operation, there's no law saying it has to be 10Hz.  Plenty of overhead 
at that speed.

Danny

On 5/3/2012 1:04 AM, Michele Bavaro wrote:
> Dear Danny,
>
> Sorry, I assumed that you read this paper
> http://gpspp.sakura.ne.jp/paper2005/isgps_2009_rtklib_revA.pdf
> before posting.
> There you may find more details about RTKLIB computational load at 10Hz.
>
> Best regards,
> Michele
>
>
> On 02/05/2012 23:08, Danny Miller wrote:
>> Well correct me if I'm wrong but this seems to come down to how many 
>> flops it can do, the moving of variables and such is probably a 
>> minority of the processing.  That's why I wanna focus on the flops 
>> requirement.
>>
>> How much resources does RTKLib consume on Beaglebone?  Because BB 
>> being faster and capable of RTKLib still doesn't establish the 
>> processing requirements.  Is it running at 60% core utilization or 5%?
>>
>> I did run RTKLib on my i7 Q 740 1.73GHz laptop and the utilization 
>> was basically nil.  I really couldn't determine anything from that, 
>> the usage figure was too low to give a meaningful number, not when 
>> the capabilities are at least 100x greater.  I mean if the usage was 
>> 10% on that i7 I could pretty well dismiss it working on a Cortex 
>> M4.  IIRC it was like a single-digit or fractional % though and the 
>> OS can consume considerable resources managing the busses and 
>> displaying the maps and interfaces so that doesn't mean much.
>>
>> Raspberry PI would be nice, but I can't get ahold of one, much less 
>> will it be readily available at this time for widespread consumption 
>> if the application worked.  I'm still uncertain if widespread, 
>> long-term, low-price distribution is gonna happen or just turn out to 
>> be vaporware.  STM32F4, anybody CAN order one or a thousand and get 
>> them for $15 or better right now.  Still got high hopes of course.  
>> Raspberry PI also wasn't designed with a lot of low-level hardware 
>> interfacing so it'd still require a daughterboard like the STM32F4 to 
>> interface with a rover's motors and sensors and all.
>>
>> Danny
>>
>> On 5/2/2012 3:40 PM, Michele Bavaro wrote:
>>> Hi Danny,
>>>
>>> I strongly doubt that a STM32F4 will be able to run RTKLIB.
>>> It's true that it runs on a beaglebone, but Cortex-A8 has around 
>>> 2MIPS/MHz and runs at frequencies close to 1GHz,
>>> whereas a Cortex-M4 has 1.25MIPS/MHz and runs at frequencies up to 
>>> 150MHz: there is almost one order of magnitude.
>>> In addition since the structure of rtkrcv is quite strongly coupled 
>>> with a Linux OS,
>>> there will be a lot of effort required to port it to a lighter RTOS, 
>>> let go to bare metal code.
>>>
>>> But I don't want to discourage you.. if you think it's doable go for 
>>> it :)
>>>
>>> Best regards,
>>> Michele
>>>
>>> On 02/05/2012 00:15, Danny Miller wrote:
>>>> STM32F4 "demo board" uses an Arm Cortex m4.  32 bit, 210 DMIPs and 
>>>> a single-precision hardware FPU.  I'm slightly unclear on the 
>>>> memory space it has on this specific board but it should be 192KB 
>>>> SRAM and 1MB flash.  That's my porting plan.
>>>>
>>>> If it WORKS, it'll be a great system, these boards are absurdly 
>>>> cheap.  It is several more orders of magnitude of capability than 
>>>> these 8bit PICs and such, but I don't understand the scale of the 
>>>> flops requirement of RTKLib.  I know it's somewhere between "much 
>>>> more than any 8-bit controller could ever do" and "won't even make 
>>>> Intel i7 break into a sweat".   And those are wildly different 
>>>> magnitudes.  I don't know exactly where RTKLib 10Hz would be 
>>>> between those.
>>>>
>>>> And it's be running RTKLib and just some minor application 
>>>> (navigation and monitoring) code which will not be 
>>>> processor-intensive, and it's not using Linux or an RTOS.  So 
>>>> there's not a significant overheat for other tasks and the 
>>>> overhead's timing can be managed predictably and accurately.  
>>>> Pretty much the core can either do it or it can't.
>>>>
>>>> Danny
>>>>
>>>> On 5/1/2012 4:43 PM, julio menezes wrote:
>>>>> Hi Danny,
>>>>>
>>>>>
>>>>>> I have a core with a hardware FPU, but it's only capable of
>>>>>> doing Single floats, not Double.  It is going to break
>>>>>> things to implement the specified Double calcs with Single
>>>>>> precision?  I would assume so, but it's worth asking.
>>>>>>
>>>>> The RTKLIB author T.Takasu and A.Yasuda have  ported RTKLIB to a 
>>>>> BeagleBoard which has an ARM Cortex-A8- with 1 GHz and floating 
>>>>> point, I do not know if double or single precision.
>>>>>
>>>>> I plan to move in this direction also, may be using a hardware 
>>>>> less powerful but cheaper.
>>>>> Raspberry Pi
>>>>> http://www.raspberrypi.org/faqs
>>>>> The SoC is a Broadcom BCM2835.
>>>>> This contains an ARM1176JZFS, with floating point, running at 
>>>>> 700Mhz, and a Videocore 4 GPU.
>>>>>
>>>>> I am waiting, anxiously,  the RTKLIB 2.4.2 version with RTCM-104 
>>>>> phase messages encoder to built a local base station as where I 
>>>>> live there are no near NTRIP network ( less than 10km ).
>>>>>
>>>>> good luck,
>>>>>
>>>>> julio menezes
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing 
>>>>> list.
>>>>> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage 
>>>>> your subscription
>>>>> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>>>>>
>>>>
>>>> _______________________________________________
>>>> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing 
>>>> list.
>>>> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage 
>>>> your subscription
>>>> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>>>
>>> _______________________________________________
>>> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
>>> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage 
>>> your subscription
>>> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>>>
>>
>> _______________________________________________
>> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
>> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your 
>> subscription
>> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your 
> subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss-gps/attachments/20120503/94290ef2/attachment-0001.html