|author||Pau Espin Pedrol <email@example.com>||2020-06-16 12:41:26 +0200|
|committer||Pau Espin Pedrol <firstname.lastname@example.org>||2020-06-16 12:42:30 +0200|
doc: Fix typos in bts-models.adoc
Diffstat (limited to 'doc/manuals')
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/manuals/chapters/bts-models.adoc b/doc/manuals/chapters/bts-models.adoc
index 4b48d4b0..495571fa 100644
@@ -248,7 +248,7 @@ current GSM frame number.
GSM is a TDMA (time division multiple access) system on the radio
interface. OsmoTRX is the "clock master" of that in the Osmocom
implementation. It informs OsmoBTS of the current GSM frame
-number. However, as there is non-zero delays (UDP packet trnsmission
+number. However, as there is non-zero delays (UDP packet transmission
delay, operating system scheduler delay on both OsmoTRX and OsmoBTS
side, ...), OsmoBTS must compensate for that delay by "advancing"
the clock a certain amount of time.
@@ -266,8 +266,8 @@ underruns on the OsmoTRX side.
The detailed value will depend on your underlying computer systems,
operating system and related tuning parameters. Running OsmoTRX
-on a remote host will inevitably require a higher fn-advance then
-running it on the same machine, where the UDP packetes are just passed
+on a remote host will inevitably require a higher fn-advance than
+running it on the same machine, where the UDP packets are just passed
over the loopback device.
The default value for `fn-advance` is 20 (corresponding to 92