INTEL 815 + Pentium III
It was fixed in 3.16 and now is back.
update:
not only 4.4… all 4.x versions !
I returned to 3.30 
I wonder if this is why Im having trouble getting an openvpn connection to work from a Soekris net4501 to my RB1000? On 4.0, 4.1 and 4.4.
no it is not, RB1000 is PPC, not x86
upgrade the BIOS?..
BIOS is the lastest ver but this is not the point.
2.x and 3.x is running without any problems.
thanks for this…yeap, it’s always hardware problem…
in 3.15 it was a hardware problem too ? no, it was fixed.
it’s no hard to figure out that MT is not interested supporting x86 platform becouse of cracking ROS and ROUTERBOARD sale.
But routerboards have poor performance (excluding rb1000 - but there is no mpci )
RB800 have about 60-70% efficiency of INTEL PIII 1000MHz- tested.
not interested? for me, RouterOS on x86 works fine. and if for a few users high-precision clock works faster, and for some of them simple upgrade of BIOS solves the problem (there were posts about that) - then the problem is probably something in hardware
Yah. But it is a Soekris x86 connecting running MT.
If clock runs 10x faster than it should on your Soekris router then answer is yes, it is the reason why OVPN is unable to connect.
yes, not interested. Insted of writing : Update BIOS… MT should do some test and check if there is any connection with bug in 3.15.
If programmers don’t know where problem is , how they can be so sure that the problem is not in ROS ?
2.x and 3.x were ok with the same x86 board.
I have the same problem as well,when i turn a wireless interface to ap bridge the clock is running x10.
Which ruins almost everything bgp timers etc.
I checked so far 3 mobos 2 p4 2.8Ghz with p65 chipset with latest bios update(8ipe1000 ver2&3).
And one ASUS P5QPL-AM with core 2 duo.
All have the same problem.
Instead of coming to your customers and saying its a hardware problem,tell us which motherboard works with your software.
Or do you suggest that i should start buying motherboards until i find one that works ok?
I remind you that it was a bug in the past and you fixed it…
*) updated drivers & kernel - fixed fast clock issue on x86;
Thanks in advance.
why dont you use routerboards ?
or just test your mainboards before putting them into production ??
mt cant test all mainboards on the market if their os runs on them
and simply dont use a ros version that makes problem with your hardware
We use routerboards but we run a pretty huge network with a lot of traffic.
So the main backbone needs a lot more horse power than a routerboard can do.
Did i say anywhere that is a production system?We are talking about testing environment.
We already running previous version of mikrotik on that hardware.
I didnt buy new hardware to update to version os 4 and 802.11n,should i?
All those questions have nothing to do with the bug though and i dont get your point really.
as far as I can see, it was fixed rather by kernel developers than by MT itself…
I have about 50 RBs out there, and am ordering 60-70 more. But I have a few sites with some X86 based boxes I want to use RouterOS on, but dont need to replace the hardware. In my case, I have some devices that I was using my own custom linux based firmware with OpenVPN and they worked fine, but MT says “If it doesnt work, it doesnt work and we cant fix it”.
PS: The clock does NOT go 10x as fast on my boxes… I just thought it might be a similar issue.
Yea but we are expecting support from mikrotik because we buy software and hardware.
Its like you getting a new car and it has a problem with tires and you go back to seller and he tells
you it’s not our problem its a problem with the tires of xxx brand.
I am just trying to say that behind the tree there is a forest with few words.
It has to do with the way that the driver uses the kernel,and starts when you use 802.11n cards in
ap bridge mode in our case.
I have a motherboard like those that have the issue in a link with r52n in client mode and the clock
is fine,if i switch it to ap bridge mode the clock is running.
Ap mode with r52 or cm9 doesnt cause an issue also.
It has to do with the PIT timer that implemented in the driver to the new releases.
P.S In some linux boxes with that similar issue with clock
the clock=pit parameter causes the Linux 2.6 kernel to use a more efficient algorithm to synchronize time.Maybe /system hardware set sourceclock-pit=yes or no ?
yes, but ROS is not free, open source, GPL project so we can’t do it by ourself right ?
I meant, MT can’t fix it until it’s fixed in the Kernel =)
clock problem was fixed twice… in 3.16 and major in 3.18 release. it was November 5th, 2008 and January 9th, 2009. No more entries in changelog about updating drivers or kernel.
Chupaka, it was a year ago. Look at the kernel.org changelog. Is’t long as toilet paper
Suriesly, I hope that someone form MT crew will try to fix this problem.