[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20051101: BGSU latencies (cont.)
- Subject: 20051101: BGSU latencies (cont.)
- Date: Tue, 01 Nov 2005 16:07:44 -0700
>From: "Patrick L. Francis" <address@hidden>
>Organization: BGSU
>Keywords: 200510312116.j9VLGv7s008531 IDD
re: I do not understand what you are asking for.
>i am sorry... i have students in and out today and was thinking
>faster than my fingers are keeping up... as soon as I try to
>work I am 'interrupted' .. 420 students is too many...
Wow, that is a heavy load!
>is why I
>keep saying verbal conversations via phone / internet
>would be more conducive to support instead of sending
>emails back and forth..
I strongly disagree. With verbal communications there is no "paper
trail". Since we make email transactions accessible to search engine
robots, others are able to learn from transactions on subjects of
interest. If we conducted support by phone, we would be spending lots
more time documenting conversations so that the information would not
be lost. We have had good feedback over the years that use of email in
our support process is extremely valuable to the community.
>anywho ;)
>
>a sample of how to adjust LDMD.CONF to specify 1,2,or 3 products to
>stream though instead of an entire feed.
OK, how I understand. The easiest way to learn how to limit requests
is use the LDM facility 'notifyme' to list out the headers of products
in a datastream. Here is a simple example for the NEXRAD Level III
feed NNEXRAD:
<as 'ldm'>
notifyme -vxl- -f NNEXRAD -o 3600
Nov 01 22:25:30 notifyme[48640] NOTE: Starting Up: localhost:
20051101212530.200 TS_ENDT {{NNEXRAD, ".*"}}
Nov 01 22:25:30 notifyme[48640] NOTE: LDM-5 desired product-class:
20051101212530.200 TS_ENDT {{NNEXRAD, ".*"}}
NOTIFYME(localhost) returns OK
Nov 01 22:25:30 notifyme[48640] NOTE: NOTIFYME(localhost): OK
Nov 01 22:25:31 notifyme[48640] INFO: 503d9768c3deccb88328b8c2b609c559 4954
20051101213631.138 NNEXRAD 45155629 SDUS53 KAPX 012128 /pNTPAPX
Nov 01 22:25:31 notifyme[48640] INFO: 07fd74d856b0c6ce5c5eff84159e48f1 4479
20051101213631.140 NNEXRAD 45155630 SDUS58 PAFC 012132 /pNTPAIH
Nov 01 22:25:31 notifyme[48640] INFO: a96a1f5d80f121c2162433cf22b0216f 3540
20051101213631.143 NNEXRAD 45155631 SDUS33 KAPX 012128 /pN1PAPX
Nov 01 22:25:31 notifyme[48640] INFO: 28127883454545bfcd5d199e42847ea8 3860
20051101213631.144 NNEXRAD 45155632 SDUS25 KABQ 012135 /pN1RFDX
Nov 01 22:25:31 notifyme[48640] INFO: d9b1de11ca3eeefc074e4f79d712f6bb 856
20051101213631.145 NNEXRAD 45155633 SDUS53 KMQT 012130 /pNCRMQT
...
Notice that there is a field in the header that says what the product
is and what the station is:
...
856 20051101213631.145 NNEXRAD 45155633 SDUS53 KMQT 012130 /pNCRMQT
^ ^__ station
|_____ product
Next use 'notifyme' to list out _only_ the NCR products from MQT:
notifyme -vxl- -f NNEXRAD -o 3600 -p NCRMQT
Nov 01 22:27:47 notifyme[48693] NOTE: Starting Up: localhost:
20051101212747.043 TS_ENDT {{NNEXRAD, "NCRMQT"}}
Nov 01 22:27:47 notifyme[48693] NOTE: LDM-5 desired product-class:
20051101212747.043 TS_ENDT {{NNEXRAD, "NCRMQT"}}
NOTIFYME(localhost) returns OK
Nov 01 22:27:47 notifyme[48693] NOTE: NOTIFYME(localhost): OK
Nov 01 22:28:03 notifyme[48693] INFO: d00abacf421b08fe5573a5ee46a8c103 857
20051101214222.845 NNEXRAD 45158813 SDUS53 KMQT 012136 /pNCRMQT
Nov 01 22:28:37 notifyme[48693] INFO: b48478115722b93280dd3e7844ae3af3 824
20051101214808.384 NNEXRAD 45161498 SDUS53 KMQT 012141 /pNCRMQT
Once you have figure out the pattern for just the products you want,
you can modify your ldmd.conf 'request' line(s) to request just those
products from the datastream. Here is an example of requesting just
the N0R (base reflectivity at tilt 1) images for all stations in the
NNEXRAD feed:
request NNEXRAD "/pN0R" idd.unidata.ucar.edu
and so on.
re: your machines are essentially idling
>yes
>
>ldm@unidata3:~/runtime/bin$ uptime
> 15:32:27 up 8 days, 21:27, 1 user, load average: 0.01, 0.11, 0.07
>
>ldm@unidata2:~/runtime/bin$ uptime
> 15:33:18 up 70 days, 22:52, 1 user, load average: 0.11, 0.19, 0.24
>
>[ldm@unidata bin]$ uptime
> 15:33:02 up 8 days, 9:21, 1 user, load average: 0.14, 0.16, 0.16
>
>[ldm@weather bin]$ uptime
> 3:33pm up 223 days, 22:50, 1 user, load average: 0.19, 0.15, 0.12
This is as I expected. I can't recall if we have ever seen machine
loading intefere with the ability of an LDM to ingest data into its
queue; the intest/relay component of the LDM uses very little system
resource.
Site-reported data problems typically fall into three categories:
- high latencies caused by external factors such as packet shapers,
slow network links, and firewall configurations
- slow processing caused by the user having one 'pqact' invocation
process all of the data being ingested
- the user machine ingesting LOTS of data and their LDM queue not
being large enough to hold the received data long enough for it
to get processed by pqact(s)
The first problem is mitigated by finding the source of the latency and
working with the appropriate contact (e.g., IT, etc.) to resolve it.
The second problem is mitigated by configuring ldmd.conf to run more
than one pqact invocation while making sure that each invocation
processes a portion of the jobs to be done (i.e., not have any overlap
in processing duties).
The third problem is mitigated by implementing the same fix for
the second problem AND by increasing the size of the queue.
Cheers,
Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web. If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.