LTPMETER(1)

📦 version 3.2.1, in ubuntu jammy

💖 LTPMETER(1) — the LTP executables crew 💖

okay bestie, sit down, grab a strawberry 🍓, because we're talking about ltpmeter, one of the LTP executables. this is the girl who takes your transmission blocks, chops them into little segments, and sends them out into the world. she's the backstage manager of the whole LTP situation and she does NOT get enough credit. 💅

✨ NAME ✨

ltpmeter — the LTP daemon task for aggregating and segmenting transmission blocks. she gathers, she splits, she ships. iconic behavior, no cap. 🎀

🌸 SYNOPSIS 🌸

ltpmeter remote_engine_nbr

that's it. one argument. she's low maintenance like that. 🦋

💫 DESCRIPTION 💫

so ltpmeter is a background "daemon" task, and her whole job is managing how LTP segments get presented to the link service output tasks. very "I run the logistics department" of her.

every single "span" of LTP data interchange between your local LTP engine and a neighboring LTP engine needs its OWN ltpmeter task. one span, one meter. she does not share. periodt.

all the ltpmeter tasks get spawned automatically by ltpadmin when you hit the 's' command that starts up LTP protocol operation. and they all get terminated by ltpadmin when you send an 'x' (STOP) command. so basically ltpadmin is the mom and all the ltpmeter tasks are the kids and the 's'/'x' commands are "dinner's ready" / "go to bed". 😭

here's the actual flow, bestie, follow along:

ltpmeter waits around until her span's current transmission block (that's the data that's going to be transmitted during the transmission session currently being constructed, iykyk) is ready for transmission. then she:

  1. divides the data in the span's block buffer into segments,
  2. enqueues those segments for transmission by the span's link service output task — and she gives the segments semaphore to unblock that link service output task whenever it's needed, 🫶
  3. reinitializes the span's block buffer,
  4. and starts another session — giving the "buffer empty" semaphore to unblock the client service task, which is nominally ltpclo, the LTP convergence layer output task for Bundle Protocol, whenever needed.

so how does she know the block is ready? she determines that the current transmission block is ready for transmission by waiting until either:

  • (a) the aggregate size of all service data units in the block's buffer exceeds the aggregation size limit for this span, or
  • (b) the length of time that the first service data unit in the block's buffer has been awaiting transmission exceeds the aggregation time limit for this span.

the "buffer full" semaphore is given when ION (either the ltp_send() function or the ltpclock daemon) figures out that one of those conditions is true. ltpmeter doesn't stress about it — she literally just waits for that semaphore to be given. queen of chilling. 👑

BUT. 💀 starting a new session can also get blocked, and here's why: the total number of transmission sessions the local LTP engine can have open at one single time is limited (that's LTP flow control, babes). and while the engine is at that limit, no new sessions can be started. availability of a session from the session pool is signaled by the "session" semaphore, which gets given whenever a session is completed or canceled. so she waits for that too. she's patient. she's booked and busy but she's patient.

🔥 EXIT STATUS 🔥

  • "0" — ltpmeter terminated normally, for reasons noted in the ion.log file. if this termination was not commanded, investigate and solve the problem identified in the log file, and use ltpadmin to restart ltpmeter. (a calm exit that you didn't ask for is still a red flag, bestie. look into it. 🙈)
  • "1" — ltpmeter terminated abnormally, for reasons noted in the ion.log file. investigate and solve the problem identified in the log file, then use ltpadmin to restart ltpmeter.

🎀 FILES 🎀

no configuration files are needed. she's self-sufficient. she's her own main character. ✨

🧚 ENVIRONMENT 🧚

no environment variables apply. nothing to set, nothing to export, we love a low-drama queen. 💜

🌈 DIAGNOSTICS 🌈

the following diagnostics may be issued to the ion.log log file. read them like texts from your bestie — they're telling you something. 💌

  • ltpmeter can't initialize LTP. — ltpadmin has not yet initialized LTP protocol operations. (she hasn't been introduced yet. give her a sec.)
  • No such engine in database. — remote_engine_nbr is invalid, or the applicable span has not yet been added to the LTP database by ltpadmin.
  • ltpmeter task is already started for this engine. — redundant initiation of ltpmeter. she's already here. she's already working. stop.
  • ltpmeter can't start new session. — an unrecoverable database error was encountered. ltpmeter terminates. 😭
  • Can't take bufClosedSemaphore. — an unrecoverable database error was encountered. ltpmeter terminates.
  • Can't create extents list. — an unrecoverable database error was encountered. ltpmeter terminates.
  • Can't post ExportSessionStart notice. — an unrecoverable database error was encountered. ltpmeter terminates.
  • Can't finish session. — an unrecoverable database error was encountered. ltpmeter terminates.
ngl, that last stretch is a LOT of "unrecoverable database error → terminates". when it rains it pours. 🫠

💀 BUGS 💀

report bugs to <ion-bugs@korgano.eecs.ohiou.edu>. tell them everything. spill the tea. they can handle it. ☕

🦋 SEE ALSO 🦋

okay that's the whole page, bestie!! go forth and segment those transmission blocks 💖✨

and before you close the tab — this one's part of the LTP executables, and the page itself was generated by perl v5.24.1 back on 2016-07-07. so yeah, she's a 2016 girlie and she's still slaying. periodt. 👑🎀

📦 where this page comes from