How to get some sort of clock signal about metarouter-apps HOT 3 CLOSED

I also looked for the same thing in the patches and similarly could not find anything.

I came to the unsatisfactory conclusion that the host MIPS RouterOS just transfers execution to the MetaROUTER ISR whenever it feels like it wants to, and this was 'good enough' for MetaROUTER Linux to function.

The MIPS "Count" register value does work and could be used as a method of evaluating whether a user timer has elapsed since the last time the MetaROUTER instance executed.

I used the "Count" register to gauge how often execution was transferred to the MetaROUTER instance. I can't remember the numbers (they varied), but it was in the 10s to 100s of times per second.

IMPORTANT: this github project was specifically published to demonstrate how MetaROUTER instances cause RouterOS to crash:

demo MetaROUTER image to crash RouterOS (with source code)
https://forum.mikrotik.com/viewtopic.php?f=15&t=113265

I really would like for there to be MetaROUTER "apps". I see lots of potential for this to provide custom functionality not in RouterOS proper. However, Mikrotik seems to have abandoned MetaROUTER from the moment it was released, and certainly shows no interest in this non-standard usage. The semi-official Linux openwrt MetaROUTER images already crashes, and this MetaDIE example definitely does crash the host RouterOS.

from metarouter-apps.

from metarouter-apps.

Yes, the macro "read_c0_count" in metarouter.h is intended as a convenient way to read that register.

I did not see a MetaROUTER patch related to timers, so I have to presume that the openwrt Linux kernel does timers in its "normal" way, whatever "normal" is. Linux kernel (MIPS or otherwise) knowledge is outside my wheelhouse. However, yes, it is my suspicion that MIPS Linux uses the Count (CP0 Register 9, Select 0) and Compare (CP0 Register 11, Select 0) registers, since this is the only timer functionality that I am aware of in the MIPS processor.

My pessimism is borne from this: just servicing MetaROUTER packets (never mind implementing timers to generate more packets) can be enough to crash the host RouterOS. I've found this to be true in 2013, and still true in 2016. This makes it impossible to implement a MetaROUTER "app" that has appealing functionality, and that in turn prevents further interest.

Discussion on Mikrotik's forum seems to just confirm the notion that Mikrotik's MetaROUTER (openwrt Linux) is nothing but a toy that should not be considered useable. I've tried a few openwrt-based implementations in long-term usage, and have only got my fingers burned. MetaROUTER instances spontaneously become unresponsive after 12-48 hours of usage and have to be manually rebooted.

Yeah, there are plenty of Mikrotik RouterOS bugs like that. "/port remote-access", for example, can't detect if a connection has been dropped, and it will refuse subsequent connections (even though the connection no longer exists).

from metarouter-apps.