1. 11 Apr, 2016 1 commit
  2. 08 Apr, 2016 1 commit
  3. 26 Jan, 2016 2 commits
  4. 18 Jan, 2016 1 commit
  5. 08 Jan, 2016 1 commit
  6. 09 Dec, 2015 1 commit
  7. 03 Dec, 2015 1 commit
  8. 02 Dec, 2015 1 commit
  9. 30 Nov, 2015 1 commit
  10. 24 Nov, 2015 1 commit
  11. 26 Oct, 2015 1 commit
  12. 30 Sep, 2015 1 commit
  13. 25 Sep, 2015 2 commits
  14. 17 Sep, 2015 1 commit
  15. 14 Sep, 2015 2 commits
  16. 06 Sep, 2015 1 commit
  17. 30 Aug, 2015 1 commit
  18. 18 Aug, 2015 1 commit
  19. 10 Aug, 2015 1 commit
  20. 04 Aug, 2015 3 commits
  21. 03 Aug, 2015 1 commit
  22. 30 Jul, 2015 2 commits
  23. 29 Jul, 2015 1 commit
  24. 27 Jul, 2015 1 commit
  25. 04 Jun, 2015 1 commit
  26. 03 Jun, 2015 1 commit
  27. 09 Apr, 2015 1 commit
  28. 19 Mar, 2015 1 commit
  29. 12 Mar, 2015 1 commit
  30. 07 Nov, 2014 1 commit
    • Jonathan Jenkins's avatar
      simplewan -> simplep2p · bd8f90c6
      Jonathan Jenkins authored
      Tired of explaining that it's not a good representation of a WAN. Instead, it's
      now a simple point-to-point latency/bandwidth model.
      bd8f90c6
  31. 20 Aug, 2014 1 commit
    • Jonathan Jenkins's avatar
      recv-side queuing support (loggp only) · 6f9bc775
      Jonathan Jenkins authored
      Rather than model-net LPs directly sending messages to other model-net LPs, LPs
      can route the intended message through the scheduler interface to be queued up
      for reception by the receiver (see the diff of loggp.c). This has the benefit of
          enabling things like priority and fairness for N->1 communication patterns.
          Currently, no packetizing is supported, and I haven't yet wrote checks for
          it - beware.
      
      Loggp is currently the only supported model. simplenet could also be supported
      without much trouble, but I doubt there's any demand for it at the moment.  This
      should NOT be used by the dragonfly/torus models, as they have their own routing
      backend.
      6f9bc775
  32. 19 Aug, 2014 1 commit
  33. 15 Aug, 2014 1 commit
    • Jonathan Jenkins's avatar
      scheduler fix for other networks (NOT torus, simplewan) · 0164aa2d
      Jonathan Jenkins authored
      Torus and simplewan each have problems precluding them from the current
      scheduling fix:
      - simplewan - each "device" has N input/output ports. It can't simply tell the
        scheduler when they are (it is?) idle because the scheduler doesn't know which
        packets go to which ports
      - torus - also has N input/output ports (two for each dimension). Also, the same
        routing "queue" (via the "next_link_available_time" var) is used for incoming
        and outgoing messages, so we can't guarantee the scheduler that we'll be
        available at time x (an incoming msg could arrive and then be routed at time
        x-1). This isn't a problem for the dragonfly network as terminals aren't
        intermediate routers. Ideally what needs to happen here is for the
        intermediate packets/chunks to be queued up in the scheduler.
      0164aa2d
  34. 08 Aug, 2014 1 commit