[OSRM-talk] Route flapping / osrm-prepare adds randomness?

Patrick Niklaus patrick.niklaus at student.kit.edu
Wed Jul 1 12:37:25 UTC 2015


Confirmed on current develop branch using the Isle of Man extract.
Currently bisecting to find out which change caused this. It is
expected that pre-processing is not 100% deterministic, since we use
parallel sorting (node IDs will change), so the JSON response will
always have a different checksum. However the geometry should always
be the same.

In theory it could happen that two paths with exactly the same travel
time get chosen in different files (because of different node ids, so
the edges are traversed in different order).

On Wed, Jul 1, 2015 at 12:20 PM, Florian Lohoff <f at zz.de> wrote:
> On Wed, Jul 01, 2015 at 10:45:36AM +0200, Florian Lohoff wrote:
>> On Tue, Jun 30, 2015 at 08:23:30PM +0200, Frederik Ramm wrote:
>> > Hi,
>> >
>> > On 06/30/2015 03:43 PM, Florian Lohoff wrote:
>> > > Okay - i am brute forcing it now with a smaller planet extract and
>> > > find disturbing results.
>> >
>> > Can you exclude a RAM defect? If you do 100 iterations of "copy large
>> > file to other large file, compare md5 sums", do you get a consistent value?
>>
>> The machine is doing a lot of other stuff - A Postgres, an OSM Task
>> Manager etc - Its an Intel Blade in an Modular Server Blade Rack.
>>
>> I dont think its memory defect. But i can try running memtest on it ...
>
> memtest86+ ran for 30 Minutes without an issue. 16GB ECC Memory Intel
> P5000 Chipset with Intel Xeon CPUs.
>
> dd if=/dev/urandom of=rfile1 bs=1M count=16000
> md5sum rfile1
> 2a806948021ffd7ef19c272bc3f88508  rfile1
> while true; do cp rfile1 rfile2; sync; md5sum rfile2; done
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
> 2a806948021ffd7ef19c272bc3f88508  rfile2
>
> Ja - ich schliesse Speicherprobleme aus.
>
> Flo
> --
> Florian Lohoff                                                 f at zz.de
>      We need to self-defense - GnuPG/PGP enable your email today!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBVZO+2JDdQSDLCfIvAQrV9g/+PzmGuhs7LVF27IhUmYW/ZrXNbs9/aw35
> ZhzZtDha5BOcks27kr0oXAvvAvXUHiL+9F58tL0X5KNSP0sd7VaqD+bKvRrJzzoy
> Dp5IG73HBXtna8VyBqNm8kBk140Xiqs9q7sxBwhDO8k5YRtpzvjZT0lh1c21rx8r
> TC+9AONcMWEpEmLwgEqJs8t0kTfSsJXBPerZGwboMgu3KyqLVjMxOzHikaxKCcsb
> IpHvo67LyiWG2pMren01p7eONXZQSbO74A1REujSi5Bbt6cpC5hHtPByjJfjw67Q
> ChiADvAmP2pNkBjyYLnEm2IfpnuWXjZwFTRhwpQst6gkV71EZQPQsQiN0SxwGA7N
> 0xcmRuNbT8gWmp7tX+szU0IiSIBrVauuWipU+8Xk+1LPAudcPpERuxG68O/rc24K
> XvFZe+zJlJfw6zyDNcFGzQUsNdFpBvRj01h5wJVicZjKTv26XEahsOKGtHcALbC0
> jSX8eep7frswf1q+gzI0HHWJBCm6eWJI+XXcQ+y7qp5KGG4ZrOAiSW1N2uXqkKWP
> oUFaFQXRDhnHtZz/jCv/3l+Di2kcuwAY1dspjdsEyVL5lkUTRZIBR7TLJajwR5en
> hFg/hmtAZTYZ9iNqT5h7OpMc3vGD5orKuqWAmhpJnHlIvwciuyrkU5eTjdSfp+Sh
> sPI4A6ROzcE=
> =nzXf
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>



More information about the OSRM-talk mailing list