Speed Test on Fez Hydra

Previously, we had been using NetDuino Plus 2 for our application, which is a single board module with 168Mhz processor.

Now, we are migrating our code from that board to FezHydra. Main reasons that motivated us to try this migration, mainly was higher amount of RAM, flash memory on FezHydra and wider support of NetMF libraries by its firmware.

In our application, boards receive some data through serial ports, run a series of operations on them and return the results. However, we noticed a considerable turnaround time between these two boards. While it took 3-4 milliseconds for Netduino board to return the result, FezHydra needed 30-31 milliseconds to return the result by performing the same operations on the same data.

Thus, we ran a very simple test to confirm the delay on FezHydra board.
The below are the snippets for FezHydra and Netduino board respectively for the purpose of testing. There was no data on port so the loop basically runs only the check (if command).


rs232.Configure(19200, GT.SocketInterfaces.SerialParity.None, GT.SocketInterfaces.SerialStopBits.One, 8, GT.SocketInterfaces.HardwareFlowControl.NotRequired);
byte[] temp;
DateTime dt1 = DateTime.Now;
for (int i = 0; i < 100000; i++)
     if (rs232.Port.BytesToRead > 0)
          temp = new byte[rs232.Port.BytesToRead];
          rs232.Port.Read(temp, 0, temp.Length);
Debug.Print(((DateTime.Now.Ticks - dt1.Ticks) / (TimeSpan.TicksPerMillisecond)).ToString());


SerialPort rs232 = new SerialPort("COM1",19200);
byte[] temp;
DateTime dt1 = DateTime.Now;
for (int i = 0; i < 100000; i++)
     if (rs232.Port.BytesToRead > 0)
          temp = new byte[rs232.Port.BytesToRead];
          rs232.Port.Read(temp, 0, temp.Length);
Debug.Print(((DateTime.Now.Ticks - dt1.Ticks) / (TimeSpan.TicksPerMillisecond)).ToString());

Basically, codes were the same. But, the results were different. The output by NetDuino is 3484 msec, while by FezHydra 16278 msec.

Now, my question is that what could cause this considerable delay? Is that because of Gadgeteer modules and the way they have been implemented in GHI Firmware?

I also suspect that there are some threads running in the background like garbage collection, etc. that could affect processing performance. If this is true, is there anyway to disable them and run them manually at desired times?

[em]Update (1) 10/10/2014:[/em]
Based on @ Architect’s suggestion, I ran the experiment by a console application on Hydra board and the results went down to 7950 to 7990 msec range, but still higher than NetDuino’s results.

For the purity of experiment I would use bare NETMF application on Hydra instead of Gadgeteer Application.

@ Architect - Could you elaborate a bit further how can I make pure NetMF application on FezHydra. The only projects that I can make are Gadgeteer projects and NetMF Console/Windows applications. Am I missing something here?

Yes, Console Application would be “native” NETMF application.
Similar to the Netduino project that you already have.

1 Like

@ Architect - Thanks. I am going to try it, and send the results.

I ran the experiment by a console application on Hydra board. The output (duration of the run) went down to 7950 to 7990 msec range. But, it is still twice of NetDuino’s output.

At this point, I can conclude:

  1. Gadgeteer applications run much slower than native NetMF applications, and I guess it is because of the way the modules are implemented. :think:

  2. I still suspect some background operations decrease the speed. Because in the console application I only included SerialPort assembly and few lines of codes, exactly the same as Netduino. Is there anyway that I can figure out what exactly runs in background, and how one can disable or enable them, if possible.

P.S. I will update my first post based on this result.

a few thoughts…

There is more than one way to impliment UART in microcontrollers. The hydra may not be using the fastest method.

The Hydra does not have an FPU like the cortex-M4 of the netduino, that divide may need more clock cycles. EDIT sorry I thought it was in the loop for some reason. It’s not so this is a red herring.

@ hagster - Thanks for sharing your thoughts. Yes, the calculation was out of the loop.

Does anyone know the clock rate of the external RAM on the hyrdra? Could this be a bottleneck?

A few thoughts.

  1. Hydra is clocked slightly faster, but it’s an old architecture. Cortex cores have much better performance characteristics.
  2. Hydra’s RAM is external, so naturally memory operations are much slower. Besides, STM chips have some frickin’ fast SRAM block connected directly to the core (at least for F40x parts), so if you are lucky to allocate your array in that region, it might make a huge difference.
  3. Both firmwares may be compiled with different compilers — this also makes a difference. Need to check, though.
  4. My test https://www.ghielectronics.com/community/forum/topic?id=16358 also show rather poor Hydra’s performance on native side. Might be due to inefficient GCC compiler that I use. Although both Cerberus (which is very similar to Netduino 2) and Hydra run almost identically at managed side.
  5. You are now allocating a new array on every operation. What if you turn it into a pre-allocated static array?

@ Simon - Thanks.

I will try it and update the results. EDIT: hagster’s question (the next post) reminded me, code never reached the declaration of byte array as no data were present on the port during the test. The times I posted only reflect for loop and IF check delays. So, I think moving byte array declaration out of the loop won’t help.

I would like to know what would be the output of the same test on G400. I don’t have one (I actually have 12 Hydra boards 8) ). That would be great if anyone can run the same test on G400, and post the results here.

What data is your UART port receiving?

@ hagster - 19200 bps EDIT: just some byte arrays. but for test nothing. The port is just checked, and since nothing is present “IF” fails.

I’ll give it a go tomorrow if I get a chance.

@ hagster - Thanks

1571ms on Raptor, FW 4.3.5.


I’m sure GHI would recommend a G400 based design over the Hydra for a professional project anyway.

Well, yeah, but it’s three times the price.

That said, the Hydra has always been the odd man out. As has been shown, the performance is insufficient to justify its continued existence, in my opinion.

What about your favorite argument — it’s frikin’ cheap?

Cerb40 is frikin’ cheap too, smaller, and not saddled with the Gadgeteer sockets. Plus it performs much better. I’d bet it uses significantly less current, too, but I’ve never measured. Now that Cerb40 is premium, it has feature parity with the other premium modules. Just better all around, I’d say.