diff --git a/Performance-Tuning.md b/Performance-Tuning.md
index 784f728..03922aa 100644
--- a/Performance-Tuning.md
+++ b/Performance-Tuning.md
@@ -110,7 +110,7 @@ schedule2 = session_save, 1200, 43200, ((session.save))
 
 ### Peers and slots
 
-`rTorrent` uses a different philosophy than most other torrent client. 
+`rTorrent` uses a different philosophy than most other torrent clients.
 
 #### Definitions
 
@@ -127,7 +127,7 @@ The `min_peers` values are responsible for asking more peers during an announce
 
 It all depends on the global connection speeds (`throttle.global_down.max_rate`, `throttle.global_up.max_rate`) and available RAM.
 
-1. every upload slot should have got at least `5 KiB/s` speed left (it's not really problem anymore with nowdays fast connection). Taking the above example, in the worst case download slots have `29 KiB/s` (`8700/300`) and upload slots have `7.3 KiB/s` (`2200/300`). That means the number of the global download slot can be increased if we notice that we run out of it.
+1. Every upload slot should have got at least `5 KiB/s` speed left (it's not really problem anymore with fast connections nowadays). Taking the above example, in the worst case download slots have `29 KiB/s` (`8700/300`) and upload slots have `7.3 KiB/s` (`2200/300`). That means the number of the global download slot can be increased if we notice that we run out of it.
 
 2. `throttle.max_downloads` and `throttle.max_uploads` slots are `50` now. In the worst case this allows downloading and uploading `6` (`300/50`) torrents at the same time, but this usually not a problem for seeding.
 
@@ -178,7 +178,7 @@ Related settings:
 
 `network.max_open_files` limits the maximum number of open files `rTorrent` can keep open. By default rTorrent uses variable sized `fd_set`'s depending on the process `sysconf(_SC_OPEN_MAX)` limit. See [Networking tweaks](#networking-tweaks) section how to adjust it system wide.
 
-Large `fd_set`'s cause a performance penalty as they must be cleared each time the client polls the sockets. When using `select` or `epoll` (until `libcurl` is fixed) based polling use an open files limit that is reasonably low (_is it still the case???_). The widely used default of `1024` is enough for most users and `64` is minimum. Those with embeded devices or older platforms might need to set the limit much lower than the default.
+Large `fd_set`'s cause a performance penalty as they must be cleared each time the client polls the sockets. When using `select` or `epoll` (until `libcurl` is fixed) based polling use an open files limit that is reasonably low (_is it still the case???_). The widely used default of `1024` is enough for most users and `64` is minimum. Those with embedded devices or older platforms might need to set the limit much lower than the default.
 
 (Due to `libcurl`'s use of `fd_set` for polling, `rTorrent` cannot at the moment move to a pure `epoll` implementation. Currently the `epoll` code uses `select` based polling if, and only if, `libcurl` is active. All `non-libcurl` sockets are still in `epoll`, but `select` is used on the `libcurl` and the `epoll`-socket. (_is it still the case???_))