From f07d69da2ddbfbd163e05ccbb90d1c1d47052a95 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 31 Jan 2023 14:32:08 +0100 Subject: [PATCH] Fix: typos (#2743) --- doc/ethereum.md | 2 +- doc/go.md | 2 +- doc/gpu.md | 2 +- doc/httpcli.md | 6 +++--- doc/ingest.md | 4 ++-- doc/multi-o.md | 4 ++-- doc/networking.md | 12 ++++++------ doc/redeemer.md | 6 +++--- doc/reliability.md | 2 +- 9 files changed, 20 insertions(+), 20 deletions(-) diff --git a/doc/ethereum.md b/doc/ethereum.md index c98d417758..a00300f69f 100644 --- a/doc/ethereum.md +++ b/doc/ethereum.md @@ -39,7 +39,7 @@ The following options can be used to set the max gas price to ``, The following options can be used to get the min gas price: - `curl localhost:7935/minGasPrice` -- Run `livepeer_cli` and observe the min gas price in the node statts +- Run `livepeer_cli` and observe the min gas price in the node stats The following options can be used to set the min gas price to ``, a Wei denominated value: diff --git a/doc/go.md b/doc/go.md index b54cc26163..bb31e2df75 100644 --- a/doc/go.md +++ b/doc/go.md @@ -16,7 +16,7 @@ There are a few ways to manage different Go versions: 1. [go install](https://go.dev/doc/manage-install) 2. [gvm](https://github.com/moovweb/gvm) -Using `gvm` has the benefit of automatically aliasing `go` to whichever version of Go you are currently using as opposed having to use a command like `go1.10.7`. +Using `gvm` has the benefit of automatically aliasing `go` to whichever version of Go you are currently using as opposed to having to use a command like `go1.10.7`. **gvm: Installing arm64 binaries on >= macOS 11** diff --git a/doc/gpu.md b/doc/gpu.md index 3b8b67adb6..826d128f07 100644 --- a/doc/gpu.md +++ b/doc/gpu.md @@ -38,7 +38,7 @@ CUDA | Nvidia 10.2 | 440.33.01, 440.118.02 11.1,11.2 | 460.39 -Nvidia's 450.xx drivers can occassionally lead to stuck transcoding sessions. +Nvidia's 450.xx drivers can occasionally lead to stuck transcoding sessions. Refer to this [forum post](https://forum.livepeer.org/t/working-around-occasional-transcoding-issues-with-nvidia-driver-450/1219) on how to switch to a different driver version. All Nvidia chipsets from [the Maxwell series](https://developer.nvidia.com/maxwell-compute-architecture) and later, that have NVDEC/NVENC cores, should theoretically be supported by go-livepeer. diff --git a/doc/httpcli.md b/doc/httpcli.md index 193d5bfad7..2a5d9e255d 100644 --- a/doc/httpcli.md +++ b/doc/httpcli.md @@ -7,11 +7,11 @@ By default, the CLI listens to localhost:7935. This can be adjusted with the -cl -`/getLogLevel` returns currrent verbosity level in the body of response +`/getLogLevel` returns current verbosity level in the body of response `/setLogLevel` sets verbosity current level. Level to set should be provided in body of the request, encoded as `application/x-www-form-urlencoded`. Parameter should be named `loglevel`. -It can be used from command like this this: +It can be used from command like this: `curl -F loglevel=6 http://localhost:7935/setLogLevel` -Log level should be integer from 0 to 6, where 6 means most verbose logging. \ No newline at end of file +Log level should be integer from 0 to 6, where 6 means most verbose logging. diff --git a/doc/ingest.md b/doc/ingest.md index 39889fff80..d11c7d5dde 100644 --- a/doc/ingest.md +++ b/doc/ingest.md @@ -68,7 +68,7 @@ Streams can be authenticated through a webhook. See the documentation on the The RTMP stream can be played back, or pulled from Livepeer by another part of the ingest infrastructure. To prevent unauthorized RTMP playback of streams whose name is known, a stream key is randomly appended to the playback URL at -ingest itme. However, the broadcaster can control the stream key by +ingest time. However, the broadcaster can control the stream key by appending the key to the RTMP URL. @@ -122,7 +122,7 @@ segment to a path ending with ".mp4" rather than ".ts", such as: http://broadcasters:8935/live/movie/14.mp4 ``` -Possble statuses returned by HTTP request: +Possible statuses returned by HTTP request: - 500 Internal Server Error - in case there was error during segment's transcode - 503 Service Unavailable - if the broadcaster wasn't able to find an orchestrator to transcode the segment - 200 OK - if transcoded successfully. Returned only after transcode completed diff --git a/doc/multi-o.md b/doc/multi-o.md index e2e7d9646a..720a757ddb 100644 --- a/doc/multi-o.md +++ b/doc/multi-o.md @@ -24,7 +24,7 @@ livepeer \ ## Single Orchestrator with Redeemer -This setup allows an operator to use a seperate Ethereum account for redeeming winning tickets on-chain and paying for that transaction while the ticket recipient is still the operator's on-chain registered Ethereum address. +This setup allows an operator to use a separate Ethereum account for redeeming winning tickets on-chain and paying for that transaction while the ticket recipient is still the operator's on-chain registered Ethereum address. The Orchestrator node will still be responsible for calling `reward`*. @@ -112,4 +112,4 @@ livepeer \ -ethOrchAddr \ -redeemerAddr \ -pricePerUnit -``` \ No newline at end of file +``` diff --git a/doc/networking.md b/doc/networking.md index 3bbc9cec25..ea41a102c6 100644 --- a/doc/networking.md +++ b/doc/networking.md @@ -5,12 +5,12 @@ ![broadcaster-transcoder network v2 1](https://user-images.githubusercontent.com/292510/41455677-c8437268-7032-11e8-9ce8-bfdd9b6e3fc0.png) [Sequence diagram source](https://sequencediagram.org/index.html#initialData=C4S2BsFMAIBkQG6QA6UgJ2gOUsA7gPboDWIAdgObQIBMAUHcgIbqgDGIzZw0ASpBRABnYOgCedAELoCTACZsmIjAFoAfP0EjxALmgB5dGwAWkbU2BE+kAI51Nw0WJXrpshUuAY9hk2dEWVvxCyAxu8orK6Oq+puaW6DoAOmQAKuhMZEJsBHIY1nbhHlEAPC6x-hkJOumZ2bn5AJJkAGYEDAzgBAShRZFe0Wq1WTl5idAAygIAtpDcBVIyEZ4YZSrD9WN6UxSz88Ghc3J0QA) -For a reference each message used by Livepeer, refer to the [Protocol Buffers definitions](https://github.com/livepeer/go-livepeer/blob/master/net/lp_rpc.proto). +For a reference to each message used by Livepeer, refer to the [Protocol Buffers definitions](https://github.com/livepeer/go-livepeer/blob/master/net/lp_rpc.proto). ## Broadcaster to Registry -The broadcaster does an on-chain lookup to retrieve the orchestrator's ServiceURI in order to discover prices, capabilities and to initiate an transcoding job. +The broadcaster does an on-chain lookup to retrieve the orchestrator's ServiceURI in order to discover prices, capabilities and to initiate a transcoding job. ## Broadcaster to Orchestrator: @@ -144,7 +144,7 @@ message TranscodedSegmentData { Currently, any errors are dumped directly into the response in stringified form. This gives broadcasters more information to diagnose problems with remote transcoders. However, we may not want to return such details forever, as this may leak internal information that is best left private to a transcoder. -Broadcasters can use the difference in time between the request submissing and the 200ok to approximate the upload time. The time between the 200ok and receiving the response body approximates the transcode time. +Broadcasters can use the difference in time between the request submission and the 200ok to approximate the upload time. The time between the 200ok and receiving the response body approximates the transcode time. There is an end-to-end request timeout of 8 seconds, However, issues are likely to appear earlier, and any issues will likely to lead to gaps in playback and stuttering. For example, live streams that consistently take 4+ seconds (the segment length) to upload and transcode will be outrun by players. @@ -187,11 +187,11 @@ message Ticket { } ``` -The `Redeemer` will send back an empty message, `QueueTicketRes` on success as well as a `200 OK` status. Upon error a `500 Internal Server Error` error code will be returned along side the error. +The `Redeemer` will send back an empty message, `QueueTicketRes` on success as well as a `200 OK` status. Upon error a `500 Internal Server Error` error code will be returned alongside the error. ### gRPC `MaxFloat`: `MaxFloatReq` -> `MaxFloatUpdate` -`MaxFloat` is a unary RPC method that is called by an Orchestrator when it requires the max float for a sender but no local cache is available. It's request takes in a sender's ethereum address: +`MaxFloat` is a unary RPC method that is called by an Orchestrator when it requires the max float for a sender but no local cache is available. Its request takes in a sender's ethereum address: ```protobuf message MaxFloatReq { @@ -209,7 +209,7 @@ message MaxFloatUpdate { ### gRPC `MonitorMaxFloat`: `MaxFloatReq` -> stream `MaxFloatUpdate` -`MonitorMaxFloat` is a server-side streming RPC method that is called by an Orchestrator to receive max float updates for a sender. The stream will remain open until either the client or the server closes the stream or connection. +`MonitorMaxFloat` is a server-side streaming RPC method that is called by an Orchestrator to receive max float updates for a sender. The stream will remain open until either the client or the server closes the stream or connection. The request follows the same format as the `MaxFloat` method: diff --git a/doc/redeemer.md b/doc/redeemer.md index a24f9e7d18..7488a1381e 100644 --- a/doc/redeemer.md +++ b/doc/redeemer.md @@ -12,7 +12,7 @@ _Max float_ is the guaranteed value an Orchestrator will be able to claim from a ## TicketQueue -1. The `ticketQueue` is a loop that runs everytime a new block is seen. It will then pop tickets off the queue starting with the oldest ticket first, and sends it to the `LocalSenderMonitor` for redemption if the `recipientRand` for the ticket has expired. +1. The `ticketQueue` is a loop that runs every time a new block is seen. It will then pop tickets off the queue starting with the oldest ticket first, and sends it to the `LocalSenderMonitor` for redemption if the `recipientRand` for the ticket has expired. 2. When the `LocalSenderMonitor` receives a ticket from the `ticketQueue` it will substract `ticket.faceValue` from the outstanding `maxFloat` as long as the ticket is in limbo. @@ -30,7 +30,7 @@ _Max float_ is the guaranteed value an Orchestrator will be able to claim from a 2. A second RPC call to `MonitorMaxFloat(sender)` will open up a server-side gRPC stream to receive future update. -_If this call fails the response from step 1 is returned, but not kept in cache to to prevent it becoming stale due to not being able to receive further updates_ +_If this call fails the response from step 1 is returned, but not kept in cache to prevent it becoming stale due to not being able to receive further updates_ 3. The `Redeemer` goroutine started by the RPC call in step 2 will start a subscription to listen for max float changes from the `LocalSenderMonitor` for the specified `sender` using `LocalSenderMonitor.SubscribeMaxFloatChange(sender)`. @@ -53,7 +53,7 @@ _Each open server-side stream will have its own subscription that will be closed So far we've discussed `LocalSenderMonitor.addFloat()` and `LocalSenderMonitor.subFloat()` being responsible for triggering `LocalSenderMonitor.SubscribeMaxFloatChange(sender)` notifications, but these can also be triggered by certain Ethereum events related to the Livepeer protocol: -- FundReserve: When a broadcaster funds it's reserve the `maxFloat` allocation increases by the added reserve divided by the active Orchestrator set size. +- FundReserve: When a broadcaster funds its reserve the `maxFloat` allocation increases by the added reserve divided by the active Orchestrator set size. - NewRound: If the active Orchestrator set size changes, the `maxFloat` will become the current broadcaster's reserve divided by the new active set size. Since this event impacts all participants in the protocol the `Redeemer` will have to send updates for _every_ `sender` it is keeping track of. ![Ethereum Events](./assets/redeemer/eth-events.png) diff --git a/doc/reliability.md b/doc/reliability.md index ec41c7de10..0d4d9cf6a9 100644 --- a/doc/reliability.md +++ b/doc/reliability.md @@ -12,7 +12,7 @@ The `BroadcastSessionsManager` stores orchestrators in two lists, a `sessList` a ## Orchestrator List Refresh -The orchestrator list is refreshed when the number of sessions in `sessList` is less than double the `HTTMPTimeout` in seconds (hard-coded to 8 seconds at the moment) divided by the lenght of segments (hard-coded to 2 seconds at the moment) OR less than the size of the OrchestratorPool saved on disk, whichever is less (i.e. when its length is less than what is required to keep in memory). This happens at startup (as described above), and when an orchestrator is selected for individual transcoding in `selectSession`. +The orchestrator list is refreshed when the number of sessions in `sessList` is less than double the `HTTMPTimeout` in seconds (hard-coded to 8 seconds at the moment) divided by the length of segments (hard-coded to 2 seconds at the moment) OR less than the size of the OrchestratorPool saved on disk, whichever is less (i.e. when its length is less than what is required to keep in memory). This happens at startup (as described above), and when an orchestrator is selected for individual transcoding in `selectSession`. ## Orchestrator Selection