Thanks for the suggestions Patrick, how do you think things would change if we needed trafic support? I guess MLD is slower than CH, could we compensate for that by putting the whole system on an SSD to make the stxxl perform better?
Thanks again, tariq ---------------------------------------------------------------------------------- Tariq Baig-Meininghaus Researcher Max Planck Institute for Dynamics and Self-Organization Department DCF/EcoBus Am Faßberg 17 37077 GÖTTINGEN GERMANY Mail: [email protected] Web: www.ds.mpg.de, ecobus.fokos.info ________________________________________ From: [email protected] [[email protected]] Sent: Wednesday, March 28, 2018 2:00 PM To: [email protected] Subject: OSRM-talk Digest, Vol 63, Issue 11 Send OSRM-talk mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/osrm-talk or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of OSRM-talk digest..." Today's Topics: 1. Suggested hardware specs for server under heavy use (Baig, Tariq) 2. Re: Suggested hardware specs for server under heavy use (Patrick Niklaus) 3. Re: OSRM 5.14.3 set kilometers long ways as small elements (Daniel Patterson) ---------------------------------------------------------------------- Message: 1 Date: Tue, 27 Mar 2018 12:49:08 +0000 From: "Baig, Tariq" <[email protected]> To: "[email protected]" <[email protected]> Subject: [OSRM-talk] Suggested hardware specs for server under heavy use Message-ID: <350c9baaf4e5894aa7907627b5508828d532f...@um-excdag-a03.um.gwdg.de> Content-Type: text/plain; charset="iso-8859-1" Dear all, we are currently working on a research project that uses osrm as a routing backend. Since we heavily rely on OSRM we would like to migrate it to a more appropriate harware setup. What would be the recommended specs for a server that provides routing for the whole of germany, and can service order of 100 - 200 table requests per second? Greetings and thanks in advance, tariq ---------------------------------------------------------------------------------- Tariq Baig-Meininghaus Researcher Max Planck Institute for Dynamics and Self-Organization Department DCF/EcoBus Am Faßberg 17 37077 GÖTTINGEN GERMANY Mail: [email protected] Web: www.ds.mpg.de, ecobus.fokos.info ------------------------------ Message: 2 Date: Tue, 27 Mar 2018 14:41:18 +0000 From: Patrick Niklaus <[email protected]> To: Mailing list to discuss Project OSRM <[email protected]> Subject: Re: [OSRM-talk] Suggested hardware specs for server under heavy use Message-ID: <cafxp+1p1ofr6_ea6pcviflau8pjqp5f4v4kwadz9gfno-gq...@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hey Tariq, This heavily depends on the settings you use and the kind of requests. For the car profile Germany should fit into 16GB of RAM, but I would calculate some buffer depending on if you need the option to exclude motorways and ferries. I'll assume you don't need traffic support? Then using or Contraction Hierarchy toolchain might be your best option. For the CPU requirement to get close to 200 req/sec it entirely depends on the kind of request (how many input coordinates). For a 100x100 matrix you can expect something like ~100ms on Germany, that would put you at 10 req per core per second. A 16 core system should probably get you in the right order of magnitude. Best, Patrick On Tue, Mar 27, 2018 at 12:49 PM, Baig, Tariq <[email protected]> wrote: > Dear all, > > we are currently working on a research project that uses osrm as a routing > backend. > Since we heavily rely on OSRM we would like to migrate it to a more > appropriate harware setup. > > What would be the recommended specs for a server that provides routing for > the whole of germany, > and can service order of 100 - 200 table requests per second? > > Greetings and thanks in advance, > > tariq > > ---------------------------------------------------------------------------------- > > Tariq Baig-Meininghaus > > Researcher > > Max Planck Institute for Dynamics and Self-Organization > Department DCF/EcoBus > > Am Faßberg 17 > > 37077 GÖTTINGEN > GERMANY > > > Mail: [email protected] > > Web: www.ds.mpg.de, ecobus.fokos.info > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk ------------------------------ Message: 3 Date: Tue, 27 Mar 2018 08:10:20 -0700 From: Daniel Patterson <[email protected]> To: Mailing list to discuss Project OSRM <[email protected]> Subject: Re: [OSRM-talk] OSRM 5.14.3 set kilometers long ways as small elements Message-ID: <canvddsk075y44ocgtmxu8bqdcw1aj62hpgjhulg3pze+wrg...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi François, > I don't understand why flagging part of the graph as "small element" prevent a route to be found. I guess you could describe this as a bug. What OSRM is trying to do is always return a route. The current approach makes sure to snap the input coordinates to edges on the same "strongly connected component", which (usually) guarantees a route will be found. There's an older blog post by Denis here: https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8 that explains the behaviour/problem that this snapping is intended to solve. This behaviour makes sense for fully disconnected components - islands, parks, etc. However, in your case, the components are weakly connected - there is a one-way path in, and an A->B route could be found, but a B->A route would not. This situation isn't really handled by the current approach. The Tarjan SCC algorithm flags *strongly connected* graph regions (full connectivity in both directions). We would need to do something quite different I think in order to do correct snapping for weakly connected components as you have in your graph. Generally in OSM, there aren't too many of these, and where they are, they're usually a mapping error (one-way roads with no exits, etc). Given that, I'm not sure it's worth spending time improving this behaviour for use with OSM data. daniel On Tue, Mar 27, 2018 at 1:58 AM, François Lacombe <[email protected] > wrote: > Hi Daniel, > > 2018-03-26 19:48 GMT+02:00 Daniel Patterson <[email protected]>: > >> Hi François, >> >> Yes, oneways onto your custom road network sound like exactly the kind >> of thing that the small component algorithm ( >> https://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected >> _components_algorithm) would flag. If your custom network is <1000 >> nodes, it would've been flagged previously. >> >> If you are only routing from the normal network *onto* your custom >> network, then changing the component size like you've done is the correct >> fix here. Just be aware, if you start on your custom network, and try to >> return to the main network, you will get "NoRoute" errors, but it sounds >> like that won't be a problem for you. >> > > This is indeed what I look for, no problem to get "No route" errors, but > only when network topology doesn't allow me to find one. > I don't understand why flagging part of the graph as "small element" > prevent a route to be found. > > I would agree to a potential downgrade of small elements versus normal > ones, but a route have to be returned when it exists, haven't you? > > >> I'm not sure what's up with the turn icons in the debug viewer - make >> sure you've zoomed in far enough, turn icons only show up from Z12 and >> higher. >> > > Yes, I look between zoom 12 and 14 > Still no turn icons > > I'm wondering if it's only a display issue or a more serious problem in my > data processing. > Anyway, osrm gives me routes with turns and intersections so this sounds > to be only a display issue. > > > All the best > > François > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20180327/4c42bfb9/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk ------------------------------ End of OSRM-talk Digest, Vol 63, Issue 11 ***************************************** _______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
