1. 30 Mar, 2016 1 commit
  2. 25 Mar, 2016 1 commit
  3. 09 Mar, 2016 1 commit
  4. 02 Mar, 2016 1 commit
  5. 13 Feb, 2016 3 commits
  6. 08 Feb, 2016 1 commit
  7. 06 Feb, 2016 1 commit
  8. 03 Feb, 2016 1 commit
    • Thomas Gardner's avatar
      trivial: various superficial fixes · 1519a59c
      Thomas Gardner authored
      misc/completion/ipfs-completion.bash: add `ipfs stats` to BASH completion
      
      core/commands/mount_unix.go: ensure error is not nil before printing it
      
      contribute.md: fix bibliography indexing in example
      
      core/commands/swarm.go: change tabs to spaces in USAGE message
      
      *: 80-column readability improvements
      
      License: MIT
      Signed-off-by: default avatarThomas Gardner <tmg@fastmail.com>
      1519a59c
  9. 31 Jan, 2016 2 commits
  10. 30 Jan, 2016 3 commits
  11. 12 Jan, 2016 4 commits
  12. 14 Dec, 2015 1 commit
  13. 05 Nov, 2015 1 commit
  14. 27 Oct, 2015 1 commit
  15. 23 Oct, 2015 1 commit
  16. 18 Oct, 2015 1 commit
  17. 12 Oct, 2015 1 commit
  18. 03 Oct, 2015 1 commit
  19. 25 Sep, 2015 1 commit
  20. 16 Sep, 2015 1 commit
  21. 15 Sep, 2015 2 commits
  22. 09 Sep, 2015 2 commits
  23. 05 Sep, 2015 1 commit
  24. 23 Aug, 2015 2 commits
  25. 04 Aug, 2015 1 commit
    • Juan Batiz-Benet's avatar
      bitswap/provide: improved rate limiting · 06b49918
      Juan Batiz-Benet authored
      this PR greatly speeds up providing and add.
      
      (1) Instead of idling workers, we move to a ratelimiter-based worker.
      We put this max at 512, so that means _up to_ 512 goroutines. This
      is very small load on the node, as each worker is providing to the
      dht, which means mostly waiting. It DOES put a large load on the DHT.
      but i want to try this out for a while and see if it's a problem.
      We can decide later if it is a problem for the network (nothing
      stops anyone from re-compiling, but the defaults of course matter).
      
      (2) We add a buffer size for provideKeys, which means that we block
      the add process much less. this is a very cheap buffer, as it only
      stores keys (it may be even cheaper with a lock + ring buffer
      instead of a channel...). This makes add blazing fast-- it was being
      rate limited by providing. Add should not be ratelimited by providing
      (much, if any) as the user wants to just store the stuff in the local
      node's repo. This buffer is initially set to 4096, which means:
      
        4096 * keysize (~258 bytes + go overhead) ~ 1-1.5MB
      
      this buffer only last a few sec to mins, and is an ok thing to do
      for the sake of very fast adds. (this could be a configurable
      paramter, certainly for low-mem footprint use cases). At the moment
      this is not much, compared to block sizes.
      
      (3) We make the providing EventBegin() + Done(), so that we can
      track how long a provide takes, and we can remove workers as they
      finish in bsdash and similar tools.
      
      License: MIT
      Signed-off-by: default avatarJuan Batiz-Benet <juan@benet.ai>
      06b49918
  26. 16 Jul, 2015 1 commit
  27. 14 Jul, 2015 3 commits