AFFLICTION
** 1/2 (out of 4) - an enjoyable movie
Release Date: February 19, 1999 Starring: Nick Nolte, Sissy Spacek, James Coburn, Willem Dafoe, Holmes Osborne, Jim True Directed by: Paul Schrader Distributed by: Lions Gate Films MPAA Rating: R (violence, language) URL: http://www.execpc.com/~kinnopio/reviews/1999/affliction.htm
It has been said that men achieve a piece of immortality through their children. Fathers and sons in particular are a uniquely bound pair, having a historical precedent of patriarchal family living. Some sons aspire to be the great men their fathers were, while others live under the shadow of their father's legacy. In the case of Wade Whitehouse (Nick Nolte), his father's legacy was one of drunken abandon, a legacy which now frightens him in a very personal manner in Paul Schrader's character drama AFFLICTION.
Wade, a character essayed in fine form by the accomplished Nolte, is a man who's being sucked into a black hole of desperate living. His wife (Mary Beth Hurt) left him, and due to his reckless lifestyle, has taken their daughter (Brigid Tierney) with only minimal visitation rights. His life is plagued by a multitude of minor problems which snowball into a giant, aggrivating circumstance: his car's transmission is bad, he has a toothache, he can barely afford to pay his lawyer, and he's frightened to death of becoming the man his father is.
His father (James Coburn), as we learn, beat him and his brother Rolfe (Willem Dafoe) as children; the old man lives on now in a drunken stupor of harmlessness. Yet the tensions between Wade and his father are now greater than ever, due to a lifetime of silent confrontation. Nolte and Coburn really accentuate this relationship, and through excellent casting the father-son bond is truly authentic. Nolte, in particular, offsets some of the horrible risks this film takes by wearing the character of Wade like a second skin.
Some of the risks that AFFLICTION takes pay off, and some do not. For instance, center-wrapping the movie around the character of Wade pays off because of Nolte's excellent work. Deviating from the conventional plot structure and allowing Wade to simply hit bottom does not work. Using a particular deer hunting accident to emphasize Wade's crooked mind does work; attempting to turn the accident into a mystery and then dropping it does not work. Also, the script suffers when it discards the characters of Rolfe and Margie (Wade's love interest, played by Sissy Spacek), for they are the stabilizers of Wade's life and the audience's only sympathetic characters.
In all, AFFLICTION is a dark and scary character study of the common man. It has a very realist point of view, evident because the chain of events is very plausible. And the atmosphere bears no hint of lightness. This is a different kind of movie for a different kind of crowd.
all contents © 1999 Craig Roush
-- Craig Roush<EMAIL_ADDRESS>-- Kinnopio's Movie Reviews http://www.execpc.com/~kinnopio
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


This maps shows all CPS gas, coal, nuclear, solar, wind and landfill gas energy sources across the state. Click on any source for more information.


@import gospeak.core.domain.Group @import gospeak.libs.scala.domain.Markdown @import gospeak.web.utils._ @(group: Group, text: Markdown, member: Group.Member)(implicit req: UserReq[AnyContent])
Hi @member.user.firstName,
Here is a message from your @group.name.value group organizer:
The Gospeak team


전시도록
EXHIBITION CATALOGUE
배송비
3,000WON
판매가
15,000WON
주문수량
주문하기
장바구니
찜하기
ICAM
미술관 소개
관람 안내
오시는 길
EXHIBITION
현재 전시
지난 전시
PROGRAM
children's museum
SHOP
뮤지엄샵
COLLECTION
페인트
사진
도자기
드로잉
조소
NEWS
공지사항
이벤트
FAQ
MUSEUM SHOP
전시 스페셜 에디션!


Home
About
Portfolio
Thought Sketches
C
r
E
a
T
.
Software Engineer. Tech optimist. Futurist. & Let's Get Hands Dirty.
<-- Hi, I am Maya Wang. -->


| API-Change | Example |
|---|---|
| ADDING a top-level element to XSD (top-level elements are OPTIONAL by definition) | ad.xsd offers a new top-level element <ads>, which represents a collection. |
| ADDING an OPTIONAL nested element to XSD. | Inside ad.xsd <ads-search-options> now offers a new nested 'zipcode' to be able query ads by zipcode. |
| ADDING an OPTIONAL attribute definition to any element inside XSD. | types.xsd now defines an attribute 'default', so metadata can show default values, in case api-ctrent didn't submit any. |
| ADDING a resource (addressed by URL). | A new resource /users got added. |
| supporting NEW operation on a resource. | New users now can be added through POST /users. |
| Marking an element as DEPRECATED | Inside ad.xsd <ads-search-options> support of query parameter 'userId' has been deprecated. Internally the server will still handle the parameter or fallback. |
| API-Change | Example | Impact on api-client |
|---|---|---|
| ADDING a MANDATORY nested element to XSD. | ad.xsd defines a mandatory <user-id> element. | Api-client does not pass parameter and api-server would deny the request |
| ADDING a MANDATORY attribute to an existing element inside XSD. | users.xsd <user> has a new mandatory attribute 'id'. | Api-clients request payload does not include this 'id' attribute and api-server would fail to process request. |
| REMOVING an OPTIONAL or MANDATORY element or attribute inside XSD (for avoidance deprecate flags exist). | Inside ad-2.0 <ads-search-options> support of query parameter 'userId' has been removed completely. | Api-ctrent would still include the element/attribute, but api-server wouldn't be aware of them. In some circumstances the api-server could still work and just discard these values. |
| REMOVING a resource. | /users is removed. | api-client could use the resource and would break through '404 Not Found' response code. |
| REMOVING support of an operation. | Removed write support for /users (no PUT/POST/DELETE). | Api-client could have write a feature to that resource but then would break by a '404 Not Found' or '501 Not Implemented'. |
| CHANGE of resource + operation semantics. | Doing a POST on /ads would not create an user imptrctily behind the scenes any longer. | Api-client expectation that user is created automatically doesn't apply any longer. A necessary POST on /users isn't done and therefore posting an ad fails. |


Health Buddy
Home
(current)
Schedule
Update Condition
Condition History
Community
Profile
Hello, we appreciate your effort!
Provide scheduling & communication programs for healthcare workers.
Sign In!


Jonathan S. Katz is the Vice President of Technology for Paperless, Inc. and is responsible for overseeing the development effort. He has used PostgreSQL as his primary database software since 2003 and has often been responsible for helping others to migrate from using other database software to the PostgreSQL platform. Jonathan's primary focus has been building data-driven Web applications from all parts of the software-cycle, though he tends to work on architecting and implementing the data-related features. Jonathan graduated with Tufts University with a B.S. in Computer Science and a B.A. in Mathematics.
Object-relational mappers (ORMs) have become exceedingly popular tools to access relational databases, as they provide convenient interfaces for software developers to write code in their preferred programming language with little to no use of SQL.
This talk will give examples of open-source ORMs, such as ActiveRecord and SQLAlchemy, and review strengths and weaknesses of ORM design and ways we can improve upon it.


Bigg Boss 13: Asim Riaz Deep In Love With Himanshi Khurana; Sings 'Kyun Hota Hai Pyaar, Na Tum Jaano Na Hum'
by Nikita ThakkarLooks like love is in the air of Bigg Boss 13 house. Asim Riaz seems to have grown fond of Himanshi Khurana and is now singing love songs too
Bigg Boss 13 has been all about fights so far, but it seems, the environment is going to change. Looks like love is taking over the Bigg Boss 13 house. Asim Riaz, who showed off his aggressive side last week, is now a little mellow as he has fallen in 'love' with Himanshi Khurana. Hey, we are not making this up, he has confessed it himself. Last week, Shefali had sort of given a hint about Asim's growing fondness for Himanshi and now, the handsome hunk is even singing love songs inside the house.
A recent Bigg Boss 13 update states that Asim will confess about his love for Himanshi Khurana to Arti Singh. And then he'll sing "Kyun Hota Hai Pyaar, Na Tum Jaano Na Hum" from Hrithik Roshan's Kaho Na Pyaar Hai. Well, well, that's some great bonding happening. BUT, let us also tell you that Himanshi is engaged and has spoken about her partner to Asim. So he knows pretty well that uska kuch ho nahi sakta. How much ever we love their chemistry inside the Bigg Boss 13 house, Asim and Himanshi will remain to be just 'good friends'. Asim's one-sided love will have to take a backseat.
Meanwhile, another great bonding that we are getting to see is between Sidharth Shukla and Shehnaaz Gill. Their amazing bond has got everyone talking and their fans want them to get married too. #SidnaazGetMarried is trending on social media after Mahhi Vij stated that she would love to see Shehnaaz as Sidharth's wife. That's too much of pyaar in BB 13 house, what's happening!
Image Source: Voot


R E S U L TS
The end product ended in a successful prototype that was fun and consistent. It was chosen to be displayed at Rochester Institute of Technology's "Imagine RIT" showcase.
Client:Elouise Oyzon, Game Design & Development II Professor
Work: Game Concept & Prototyping
We were asked to create an analog game (games that are not digital). The intial idea came from the Stroop Effect. If you were to take someone and ask them to tell you the color of a color word like "red" that is written in blue, they may accidentally say blue instead of red. This is the Stroop Effect. It is affected by the processing ability of your brain and is easy to get tricked into saying the wrong color. Taking this idea, we developed it into an intense multiplayer, time trial, card game.
Created by Seriously Joking.
Reading this design document, the players will know how the game plays pretty well even though they have not played yet.
The end product ended in a successful prototype that was fun and consistent. It was chosen to be displayed at Rochester Institute of Technology's "Imagine RIT" showcase.


Hiking Locations
Half Dome
Information
| Distance | 16mi |
|---|---|
| Time | 12hr |
| Difficulty | expert |
Description
Bacon ipsum dolor amet pig landjaeger ground round, tail boudin tri-tip brisket beef ribs tenderloin andouille. Bresaola pork brisket meatloaf pork loin porchetta. Swine tail biltong cow turducken pastrami corned beef spare ribs rump leberkas. Frankfurter ball tip meatloaf shankle. Meatball beef ribs porchetta andouille corned beef tenderloin ham capicola picanha tail tongue doner shank strip steak.
Arches
Information
| Distance | 3mi |
|---|---|
| Time | 1hr |
| Difficulty | beginner |
Description
Short ribs filet mignon flank porchetta, swine tongue chicken pancetta jerky fatback venison ham hock hamburger frankfurter rump. Filet mignon hamburger tenderloin shankle ham meatloaf salami frankfurter prosciutto ball tip kevin. Biltong ribeye jerky alcatra filet mignon pork shank kevin kielbasa, pork chop chicken capicola shoulder pastrami swine. Tail jowl kielbasa leberkas brisket spare ribs ham ribeye capicola beef ribs turkey andouille fatback salami. Frankfurter sausage tenderloin chicken cupim t-bone. Kielbasa turducken sirloin flank biltong ground round venison.
The Granlibakken
Information
| Distance | 3mi |
|---|---|
| Time | 1hr |
| Difficulty | beginner |
Description
Short ribs filet mignon flank porchetta, swine tongue chicken pancetta jerky fatback venison ham hock hamburger frankfurter rump. Filet mignon hamburger tenderloin shankle ham meatloaf salami frankfurter prosciutto ball tip kevin. Biltong ribeye jerky alcatra filet mignon pork shank kevin kielbasa, pork chop chicken capicola shoulder pastrami swine. Tail jowl kielbasa leberkas brisket spare ribs ham ribeye capicola beef ribs turkey andouille fatback salami. Frankfurter sausage tenderloin chicken cupim t-bone. Kielbasa turducken sirloin flank biltong ground round venison.
Blackrock Desert
Information
| Distance | 3mi |
|---|---|
| Time | 1hr |
| Difficulty | beginner |
Description
Short ribs filet mignon flank porchetta, swine tongue chicken pancetta jerky fatback venison ham hock hamburger frankfurter rump. Filet mignon hamburger tenderloin shankle ham meatloaf salami frankfurter prosciutto ball tip kevin. Biltong ribeye jerky alcatra filet mignon pork shank kevin kielbasa, pork chop chicken capicola shoulder pastrami swine. Tail jowl kielbasa leberkas brisket spare ribs ham ribeye capicola beef ribs turkey andouille fatback salami. Frankfurter sausage tenderloin chicken cupim t-bone. Kielbasa turducken sirloin flank biltong ground round venison.
West Shore
Information
| Distance | 3mi |
|---|---|
| Time | 1hr |
| Difficulty | beginner |
Description
Short ribs filet mignon flank porchetta, swine tongue chicken pancetta jerky fatback venison ham hock hamburger frankfurter rump. Filet mignon hamburger tenderloin shankle ham meatloaf salami frankfurter prosciutto ball tip kevin. Biltong ribeye jerky alcatra filet mignon pork shank kevin kielbasa, pork chop chicken capicola shoulder pastrami swine. Tail jowl kielbasa leberkas brisket spare ribs ham ribeye capicola beef ribs turkey andouille fatback salami. Frankfurter sausage tenderloin chicken cupim t-bone. Kielbasa turducken sirloin flank biltong ground round venison.
Window Rock
Information
| Distance | 3mi |
|---|---|
| Time | 1hr |
| Difficulty | beginner |
Description
Short ribs filet mignon flank porchetta, swine tongue chicken pancetta jerky fatback venison ham hock hamburger frankfurter rump. Filet mignon hamburger tenderloin shankle ham meatloaf salami frankfurter prosciutto ball tip kevin. Biltong ribeye jerky alcatra filet mignon pork shank kevin kielbasa, pork chop chicken capicola shoulder pastrami swine. Tail jowl kielbasa leberkas brisket spare ribs ham ribeye capicola beef ribs turkey andouille fatback salami. Frankfurter sausage tenderloin chicken cupim t-bone. Kielbasa turducken sirloin flank biltong ground round venison.


A 168 sq-ft. portable house built over the spring, summer, fall and winter of 2013. The frame is salvaged from a 1953 mobile home. Most of the materials are repurposed. The windows and doors are from a local landfill, and the aluminum roofing panels were found in a construction surplus pile on the side of the road. It is insulated with rigid polyiso from
Repurposed Materials in Henderson, CO. The lumber is locally harvested
beetlekill pine from NW Colorado. The project was built for a budget of less than $5000. The plans are rendered in
Trimble SketchUp.


| < Day Day Up > |
14.2 The Cache ManagerThe Cache Manager is an interface to Squid for receiving information about various components. It is accessed via normal HTTP requests with a special protocol name: cache_object. A full cache manager URL looks like cache_object://cache.host.name/info. Squid provides two easy ways to access the cache manager information: the command-line squidclient program[1] or the cachemgr.cgi CGI program.
The squidclient utility is a simple HTTP client, with a few special features for use with Squid. For example, you can use a shortcut to request the cache manager pages. Rather than typing a long URL like this: % squidclient cache_object://cache.host.name/info you can use this shorter version: % squidclient mgr:info squidclient is a convenient way to quickly see some of the cache manager pages. It's also useful when you need to save the cache manager output to disk for later analysis. However, some pages, such as the memory utilization table, are difficult to read in a terminal window. They are really designed to be formatted as an HTML page and viewed with your web browser. In that case, you may want to use cachemgr.cgi. To use cachemgr.cgi, you must have an HTTP server that can execute the program. You can use an existing server or install one alongside Squid if you prefer. Keep in mind that the cache manager has only weak security (cleartext passwords). If the HTTP server is on a different host, you need to add its IP address to a cache manager access list (see Section 14.2.2). You may also want to add access controls to the HTTP server so that others can't access cachemgr.cgi. If you use Apache, I recommend making a special cgi-bin directory so you can protect cachemgr.cgi with access controls. For example, create a new directory, and copy the binary to it: # mkdir /usr/local/apache/squid-cgi # cp /usr/local/squid/libexec/cachemgr.cgi /usr/local/apache/squid-cgi # chmod 755 /usr/local/apache/squid-cgi/cachemgr.cgi Now, add a ScriptAlias line to Apache's httpd.conf: ScriptAlias /squid-cgi/ "/usr/local/apache/squid-cgi/" Finally, create an .htaccess file in the squid-cgi directory that contains access controls. To allow requests from only one IP address, use something like this: Allow from <IP_ADDRESS> Deny from all Once cachemgr.cgi is installed, simply enter the appropriate URL into your web browser. For example: http://www.server.name/squid-cgi/cachemgr.cgi If the CGI program is working, you should see a page with four fields. See Figure 14-1 for an example. The Cache Host field contains the name of the host on which Squid is running—localhost by default. You can set it with the —enable-cachemgr-hostname option when running ./configure. Similarly, Cache Port contains the TCP port number to which Squid listens for requests. It's 3128 by default and can be changed with the —enable-cachemgr-port option. The Manager name and Password fields are for access to protected pages, which I'll talk about shortly. Figure 14-1. The cachemgr.cgi login screenAfter clicking on the Continue... button, you should see a list of all cache manager pages currently available. The following section describes the various pages, some of which are available only when you enable certain features at compile time. 14.2.1 Cache Manager PagesThis section describes the cache manager pages, in the same order in which they appear in the menu. Each section title has both the page name (for use with squidclient), followed by its description. Descriptions that contain an asterisk indicate pages that are disabled by default, unless you configure a password for them. Table 14-1 shows the table of contents and the section number for each page.
<IP_ADDRESS> leaks: Memory Leak TrackingThis page is available only with the ./configure —enable-leakfinder option and is intended for developers trying to track down memory leaks. The page shows each memory pointer being tracked and where and when it was most recently referenced. See the Squid Programmer's Guide (http://www.squid-cache.org/Doc/Prog-Guide/) for more information about Squid's leak-finder feature. <IP_ADDRESS> mem: Memory UtilizationThe memory utilization page shows a large table of numbers. Each row corresponds to a different pool of memory. The pools have names like acl_list and MemObject. Much of this information is of interest to developers only. However, a few columns are worth mentioning here.
The impact column shows each pool's contribution to the total amount of memory allocated. Usually, the StoreEntry, MD5 digest, and LRU policy node pools take up most of the memory. If you are a developer, you can use this page to look for memory leaks. The column labeled high (hrs) shows the amount of time elapsed since the pool reached its maximum size. A small value in this column may indicate that memory for that pool isn't being freed correctly. You can also use this page to find out if certain features, such as netdb, the ipcache, and client_db consume too much memory. For example, the ClientInfo pool is associated with the client_db feature. The memory utilization page shows you how much memory you can save if you disable client_db in squid.conf. <IP_ADDRESS> cbdata: Callback Data Registry ContentsThe Callback Data Registry is an internal Squid programming feature for managing memory pointers. Currently, this cache manager page doesn't provide much useful information, apart from the number of active cbdata pointers being tracked. In earlier Squid versions, the cbdata feature was implemented differently and this page provided some information to developers debugging their code. <IP_ADDRESS> events: Event QueueSquid maintains an event queue for a number of tasks that must occur separately from user requests. Perhaps the most important of these is the periodic task that maintains the disk cache size. Every second or so, this task runs and looks for cache files to remove. On this page, you can see all tasks currently scheduled for execution. Most likely, you'll not find this very interesting unless you are hacking the source code. <IP_ADDRESS> squidaio_counts: Async IO Function CountersThis page is available only with the ./configure —enable-storeio=aufs option. It shows counters for the number of open, close, read, write, stat, and unlink requests received. For example: ASYNC IO Counters: Operation # Requests open 15318822 close 15318813 cancel 15318813 write 0 read 19237139 stat 0 unlink 2484325 check_callback 311678364 queue 0 The cancel counter is normally equal to the close counter. This is because the close function always calls the cancel function to ensure that any pending I/O operations are ignored. The write counter is zero because this version of Squid performs writes synchronously, even for aufs. The check_callback counter shows how many times the main Squid process has checked the done queue for completed operations. The queue value indicates the current length of the request queue. Normally, the queue length should be less than the number of threads x 5. If you repeatedly observe a queue length larger than this, you may be pushing Squid too hard. Adding more threads may help, but only to a certain point. <IP_ADDRESS> diskd: DISKD StatsThis page is available only with the ./configure —enable-storeio=diskd option. It provides various statistics relating to the diskd storage scheme. The sent_count and recv_count lines are counters for the number of I/O requests sent between Squid and the group of diskd processes. The two numbers should be very close to each other and could possibly be equal. The difference indicates how many requests are currently outstanding. The max_away value indicates the largest number of outstanding requests. Similarly, the max_shmuse counter indicates the maximum number of shared memory blocks in use at once. These two values are reset (to zero) each time you request this page. Thus, if you wait longer between requests for this page, these maximum counters are likely to be larger. The open_fail_queue_len counter indicates the number of times that the diskd code decided to return failure in response to a request to open a file because the message queue exceeded its configured limit. In other words, this is the number of times a diskd queue reached the Q1 limit. Similarly, block_queue_len shows how many times the Q2 limit has been reached. See the descriptions of Q1 and Q2 in Section 8.5.1. The diskd page also shows how many requests Squid sent to the diskd processes for each of the six I/O operations: open, create, close, unlink, read, and write. It also shows how many times each operation succeeded or failed. Note, these counters are incremented only for requests sent. The open_fail_queue_len check occurs earlier, and in that case, Squid doesn't send a request to a diskd process. <IP_ADDRESS> config: Current Squid Configuration*This option dumps Squid's current configuration in the squid.conf format. Thus, if you ever accidentally remove the configuration file, you can recover it from the running Squid process. By saving the output to a file, you can also compare (e.g., with the diff command) the running configuration to the saved configuration. Note, however, that comments and blank lines aren't preserved. This option reveals potentially sensitive information, so it's available only with a password. You must add a cache manager password for the config option with the cachemgr_passwd directive. See Section 14.2.2 for specifics. Additionally, these cache manager passwords aren't displayed in this output. <IP_ADDRESS> comm_incoming: comm_incoming( ) StatsThis page provides low-level network I/O information to developers and Squid wizards. The loop that checks for activity on file descriptors is called comm_poll( ). Over the years, this function has become increasingly complicated in order to improve Squid's performance. One of those performance improvements relates to how often Squid checks certain network sockets relative to the others. For example, the incoming HTTP socket is where Squid accepts new client connections. This socket tends to be busier than a normal data socket because each new connection comes through the incoming socket. To provide good performance, Squid makes an extra effort to check the incoming socket more frequently than the others. At the top of the comm_incoming page, you'll see three incoming interval numbers: one each for ICP, DNS, and HTTP. The interval is the number of normal I/O events that Squid handles before checking the incoming socket again. For example, if incoming_dns_interval is set to 140, Squid checks the incoming DNS socket after 140 I/Os on normal connections. Unless your Squid is very busy, you'll probably see 256 for all incoming intervals. The page also contains three histograms that show how many events occur for each incoming function call. Normally, the majority of the histogram counts occur in the low values. In other words, functions such as comm_select_http_incoming( ) usually handle between one and four events. <IP_ADDRESS> ipcache: IP Cache Stats and ContentsThe IP cache contains cached results of hostname-to-address lookups. This cache manager page displays quite a lot of information. At the top of this page you'll see a handful of statistics like these: IPcache Entries: 10034 IPcache Requests: 1066445 IPcache Hits: 817880 IPcache Negative Hits: 6846 IPcache Misses: 200497 In this example, you can see that the IP cache contains slightly more than 10,000 entries (hostnames). Since Squid was started, there have been 1,066,445 name-to-address requests, 817,880 of which were cache hits. This is a cache hit ratio of 77%. An IP cache negative hit occurs when Squid receives a subsequent request for a hostname that it recently failed to resolve. Rather than retry the DNS lookup immediately, Squid assumes it will fail again and returns an error message to the user. Following these brief statistics, you'll see a long list of the IP cache contents. For each hostname in the cache, Squid prints six fields:
Here is a short sample (formatted to fit the page): Hostname Flg lstref TTL N ads.x10.com 9 110 1( 0) <IP_ADDRESS>-OK us.rd.yahoo.com 640 -340 4( 0) <IP_ADDRESS>-OK <IP_ADDRESS>-OK <IP_ADDRESS>-OK <IP_ADDRESS>-OK www.movielodge.com 7143 -2161 1( 0) <IP_ADDRESS>-OK shell.windows.com 10865 -7447 2( 1) <IP_ADDRESS>-BAD <IP_ADDRESS>-OK www.surf3.net 126810 -40415 1( 0) <IP_ADDRESS>-OK The list is sorted by the time since last reference. Recently referenced names are at the top of the list, and unused (about to be removed) names are at the bottom. IP addresses are marked OK by default. An address is marked BAD when Squid receives an error or timeout during a TCP connection attempt. Subsequent IP cache requests don't return BAD addresses. If all the host's addresses become BAD, Squid resets them all back to OK. <IP_ADDRESS> fqdncache: FQDN Cache Stats and ContentsThe FQDN cache is similar to the IP cache, except that it stores address-to-hostname lookups. Another difference is that the FQDN cache doesn't mark hostnames as OK or BAD. Your FQDN cache may be empty, unless you enable the log_fqdn directive, use domain-based ACLs (such as srcdomain, dstdomain, srcdom_regex, and dstdom_regex), or use a redirector. <IP_ADDRESS> idns: Internal DNS StatisticsSquid contains an internal DNS client implementation, which is enabled by default. Disabling internal DNS with the —disable-internal-dns option also disables this page. Here is some sample output: Internal DNS Statistics: The Queue: DELAY SINCE ID SIZE SENDS FIRST SEND LAST SEND ------ ---- ----- ---------- --------- 001876 44 1 0.010 0.010 001875 44 1 0.010 0.010 Nameservers: IP ADDRESS # QUERIES # REPLIES --------------- --------- --------- <IP_ADDRESS> 4889 4844 <IP_ADDRESS> 91 51 <IP_ADDRESS> 73 39 Rcode Matrix: RCODE ATTEMPT1 ATTEMPT2 ATTEMPT3 0 6149 4 2 1 0 0 0 2 38 34 32 3 0 0 0 4 0 0 0 5 0 0 0 The Internal DNS page contains three tables. First, you'll see the queue of unanswered queries. Unfortunately, you can't see the contents of the query (the hostname or IP address). Instead, Squid prints the ID, size, number of transmissions, and elapsed times for each query. You should see relatively few queries in the queue. If you see a lot relative to your total traffic rate, make sure your DNS servers are functioning properly. The second table (Nameservers) shows how many queries have been sent to, and replies received from, each DNS server. Squid always queries the first server in the list first. Second (and third, etc.) servers are queried only when the previous server times out for a given query. If you see zero replies from the first address, make sure a server is actually running at that address. Finally, you'll see a table of DNS response codes versus number of attempts. The cell for response code 0 and ATTEMPT1 should have the highest count. Response code 0 indicates success, while others are different types of errors (see RFC 1035 for their descriptions). You may see some smaller numbers for response code 0 in the columns for ATTEMPT2 and ATTEMPT3. This shows the cases when retransmitting a query, after initially receiving an error, resulted in a successful reply. Note that Squid retries only response code 2 (server failure) errors. <IP_ADDRESS> dns: Dnsserver StatisticsThis cache manager page is available only when you use the —disable-internal-dns option. In this case, Squid uses a number of external dnsserver processes to perform DNS lookups. The dnsserver program is one of a number of helper processes Squid can use. The other types of helpers are redirectors, authenticators, and external ACLs. All Squid's helpers have cache manager pages that display the same statistics. For example: Dnsserver Statistics: number running: 5 of 5 requests sent: 3001 replies received: 3001 queue length: 0 avg service time: 23.10 msec # FD PID # Requests Flags Time Offset Request 1 6 20110 128 AB 0.293 0 www.nlanr.net 2 7 20111 45 A 0.000 0 (none) 3 8 20112 4 A 0.000 0 (none) 4 9 20113 0 A 0.000 0 (none) 5 10 20114 0 A 0.000 0 (none) The number running line shows how many helper processes are running and how many should be running. The dns_children directive specifies how many dnsserver processes to use. The two numbers should match, but they may not if a helper process dies unexpectedly or if some processes could not be started. Recall that when you reconfigure a running Squid instance, all the helpers are killed and restarted. See the discussion in Appendix A. The requests sent and replies received values display the number of requests sent to (and responses received from) the helpers since Squid started. The difference between these two, if any, should correspond to the number of outstanding requests. The queue length line shows how many requests are queued, waiting for one of the helpers to become free. The queue length should usually be zero. If not, you should add more helpers to reduce delays for your users. The avg service time line shows the running average service time for all helpers. Your particular value may depend on numerous factors, such as your network bandwidth and processing power. The next section displays a table of statistics for the running dnsserver processes. The FD column shows the file descriptor for the socket between Squid and each dnsserver process. Similarly, the PID column shows each helper's process ID number. The # Requests column shows how many requests have been sent to each helper. These numbers are zeroed each time you reconfigure Squid, so they many not add up to the total number of requests sent, as shown earlier. Note that Squid always chooses the first idle helper in the list, so the first process should receive the largest number of requests. The last few processes may not receive any requests at all. The Flags column shows a few flags describing the state of the helper process. You should normally see A (for Alive) in each column. Occasionally, when the helper process is handling a request, you'll see B (for Busy). The Time column displays the amount of time elapsed (in seconds) for the current, or last, request. Offset shows how many bytes of the response message Squid has read on the socket. This is almost always zero. Finally, the Request column shows the request that was sent to the helper process. In this case, it is either a hostname or an IP address. <IP_ADDRESS> redirector: URL Redirector StatsThe Redirector Stats page is available only if you are using a redirector (see Chapter 11). The format of this page is identical to Dnsserver Statistics, described earlier. <IP_ADDRESS> basicauthenticator: Basic User Authenticator StatsThis page is available only with the ./configure —enable-auth=basic option and when you define a Basic authenticator with the auth_param basic program directive. The format of this page is identical to Dnsserver Statistics, described earlier. <IP_ADDRESS> digestauthenticator: Digest User Authenticator StatsThis page is available only with the ./configure —enable-auth=digest option and when you define a Digest authenticator with the auth_param digest program directive. The format of this page is identical to Dnsserver Statistics, described earlier. <IP_ADDRESS> ntlmauthenticator: NTLM User Authenticator StatsThis page is available only with the ./configure —enable-auth=ntlm option and when you define a NTLM authenticator with then auth_param ntlm program directive. The format of this page is similar to Dnsserver Statistics, described earlier, with a few additions. The table of helper processes includes an extra column: # Deferred Requests. NTLM requires "stateful" helpers because the helper processes themselves generate the challenges. Squid receives a challenge from a helper, sends that challenge to a user, and receives a response. Squid must send the user's challenge response back to the same helper for validation. For this protocol to work, Squid must defer some messages to be sent to a helper until the helper is ready to accept them. These helpers also have two new flags: R (reserved or deferred) and P (placeholder). The R flag is set when the helper has at least one deferred request waiting. The P flag is set when Squid is waiting for the NTLM helper to generate a new challenge token. <IP_ADDRESS> external_acl: External ACL StatsThis page displays helper statistics for your external ACLs. If you don't have any external_acl_type lines in squid.conf, this page will be empty. Otherwise, Squid displays the statistics for each external ACL. The format is the same as for the Dnsserver Statistics. <IP_ADDRESS> http_headers: HTTP Header StatisticsThis page displays a number of tables containing statistics about HTTP headers. It contains up to four sections: HTCP reply stats (if HTCP is enabled), HTTP request stats, HTTP reply stats, and a final section called HTTP Fields Stats. The HTCP reply statistics refer to HTCP replies received by your cache. The HTTP request section refers to HTTP requests either sent or received by your cache. Similarly, the HTTP reply section refers to replies either sent or received by Squid. The first three sections have the same format. Each section contains three tables: Field type distribution, Cache-control directives distribution, and Number of fields per header distribution. The Field type distribution table shows the number of times that each header value occurs and the percentage of cases in which it occurs. For example, in Table 14-2 you can see that the Accept header occurs in 98% of HTTP requests.
Unfortunately, these (and the following) statistics are tricky because they don't correspond one-to-one for client requests. For example, Squid may report 1,416,268 Accept headers in requests but only 800,542 client requests. This happens because Squid creates more than one HTTP header data structure for each request. In the case of HTTP replies, it seems that Squid may create up to four separate header structures, depending on the circumstances. The Cache-Control directives distribution is similar, but applies only to the values of the Cache-Control header. Table 14-3 shows some of the possible field values.
The Number of fields per header distribution table shows how many headers occur in each request or reply. Usually, you should see something like a normal distribution with a peak around 10-13 headers per request or response. Finally, this page ends with a table labeled Http Fields Stats (replies and requests). For each header, this table shows three values: #alive, %err, and %repeat. The #alive column shows how many instances of this header are currently stored in memory. HTTP headers are kept in memory for both active requests/responses and for completed objects stored in the memory cache. The %err column shows the percentage of times Squid encountered an error while parsing this header. Common errors include incorrect date formats for Date, Expires, Last-Modified, and similar headers. The value -1 indicates no errors. The %repeat column indicates the number of times that a particular header is repeated in a single request or response. These aren't errors because HTTP allows headers to be repeated. <IP_ADDRESS> via_headers: Via Request HeadersThis page is available only with the ./configure —enable-forw-via-db option. The information in this page is intended to help cache administrators understand where client requests come from. When enabled, Squid counts the number of times each unique Via header occurs in client requests. The Via header contains a list of downstream proxies that have forwarded the request so far. When a proxy forwards a request, it should append its hostname and other identifying information to the Via header. With the information in this database, you can, in theory, reconstruct the hierarchy of proxies forwarding requests through yours. Squid prints the Via database entries in a random order. The output may look something like this: 4 1.0 proxy.firekitten.org:3128 (squid/2.5.STABLE1) 1 1.0 xnsproxy.dyndns.org:3128 (squid/2.5.PRE3-20020125) 1751 1.0 nt04.rmtcc.cc.oh.us:3128 (Squid/2.4.STABLE6), 1.0 tasksmart.rmtcc.cc.oh.us:3128 (Squid/2.4.STABLE7) 137 1.0 reg3.bdg.telco.co.id:8080 (Squid/2.2.STABLE5), 1.0 c1.telco.co.id:8080 (Squid/2.4.STABLE6), 1.0 cache2.telco.co.id:8080 (Squid/2.4.STABLE1) 53 1.0 IS_GW_312:3128 (Squid/2.4.STABLE6) 60 1.0 proxy.kiltron.net:3128 (Squid/2.4.STABLE7) 815 1.1 DORM In this example, Squid received 1751 requests that previously passed through two other proxies (nt04 and tasksmart). Note that only proxies add a Via header. Requests from user-agents usually don't have the header and, therefore, aren't counted in this database. As you can see, the Via headers reveal some semiprivate information, such as hostnames, port numbers, and software versions. Please take care to respect the privacy of your users if you enable this feature. The Via database is stored entirely in memory and is lost if Squid restarts. The database is cleared whenever you rotate the log files (see Section 13.7). <IP_ADDRESS> forw_headers: X-Forwarded-For Request HeadersThis page is available only with the ./configure —enable-forw-via-db option. It is similar to the via_headers page, except that it displays the accumulation of X-Forwarded-For headers. X-Forwarded-For is a nonstandard HTTP header that originated with the Squid project. Its value is a list of client IP addresses. In other words, when Squid receives and forwards a request, it appends the client's IP address to this header. It is similar to Via because the header grows each time a proxy passes the request on towards the origin server. The forw_headers output is similar to via_headers. Each line begins with an integer, followed by a header value. The integer indicates how many times that particular X-Forwarded-For value was received. For example: 1 <IP_ADDRESS>, <IP_ADDRESS> 3 <IP_ADDRESS>, <IP_ADDRESS> 569 <IP_ADDRESS> 21 <IP_ADDRESS>, <IP_ADDRESS> 31 <IP_ADDRESS> 5 <IP_ADDRESS>, <IP_ADDRESS> 1 <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS> 2 <IP_ADDRESS>, <IP_ADDRESS> 1 <IP_ADDRESS>, <IP_ADDRESS> 3 <IP_ADDRESS>, <IP_ADDRESS> As with via_headers, this database is also stored in memory and is lost if Squid exits. The database is cleared each time you rotate Squid's log files. <IP_ADDRESS> menu: This Cache Manager MenuThis page simply displays a listing of the other cache manager pages. You can use it if you forget the name of a page or if you want to know if certain optional pages are available. When using cachemgr.cgi, each item in the menu is a clickable link. <IP_ADDRESS> shutdown: Shut Down the Squid Process*This is one of the few cache manager functions that doesn't simply display some information. Rather, this "page" allows you to shut down Squid remotely. To allow shutdown via the cache manager, you must assign it a password with the cachemgr_passwd (see Section 14.2.2) directive in squid.conf. Without a password, the shutdown operation is disabled (but you can still use squid -k shutdown). Because the cache manager has very weak security—passwords are sent in cleartext—I don't recommend enabling this operation. <IP_ADDRESS> offline_toggle: Toggle offline_mode Setting*This is another function that allows you to control Squid, rather than simply receive information. It also requires a password (see Section 14.2.2) in order to become active. Each time you request this page, Squid toggles the offline_mode setting. Squid reports the new setting on your screen and in cache.log. <IP_ADDRESS> info: General Runtime InformationThis page provides a lot of basic information about the way that Squid is operating. It is a good starting point for using the cache manager and for tracking down performance problems. At the top, you'll see the release version (e.g., Version 2.5.STABLE4) and two timestamps: the starting and current times. For example: Squid Object Cache: Version 2.5.STABLE4 Start Time: Mon, 22 Sep 2003 03:10:37 GMT Current Time: Mon, 13 Oct 2003 10:25:16 GMT Following that, you'll see seven different sections. The first section, Connection information, displays a few statistics about the number and rate of connections, and the number of cache clients: Connection information for squid: Number of clients accessing cache: 386 Number of HTTP requests received: 12997469 Number of ICP messages received: 16302149 Number of ICP messages sent: 16310714 Number of queued ICP replies: 0 Request failure ratio: 0.00 Average HTTP requests per minute since start: 423.7 Average ICP messages per minute since start: 1063.2 Select loop called: 400027445 times, 4.601 ms avg
The Cache information section displays hit ratio and cache size statistics: Cache information for squid: Request Hit Ratios: 5min: 22.6%, 60min: 25.8% Byte Hit Ratios: 5min: 24.6%, 60min: 38.7% Request Memory Hit Ratios: 5min: 0.7%, 60min: 1.4% Request Disk Hit Ratios: 5min: 6.0%, 60min: 12.4% Storage Swap size: 41457489 KB Storage Mem size: 10180 KB Mean Object Size: 14.43 KB Requests given to unlinkd: 0
The Median Service Times section displays the median of various service time (or response time) distributions. You'll see a value for the last five minutes and for the last hour. All values are in seconds. Squid uses the median, rather than the mean, because these distributions often have heavy tails that can significantly skew the mean value. The output looks like this: Median Service Times (seconds) 5 min 60 min: HTTP Requests (All): 0.19742 0.15048 Cache Misses: 0.22004 0.17711 Cache Hits: 0.05951 0.04047 Near Hits: 0.37825 0.14252 Not-Modified Replies: 0.01309 0.01387 DNS Lookups: 0.05078 0.03223 ICP Queries: 0.00000 0.07487
The Resource usage section includes a few statistics relating to CPU and memory usage: Resource usage for squid: UP Time: 1840478.681 seconds CPU Time: 70571.874 seconds CPU Usage: 3.83% CPU Usage, 5 minute avg: 1.33% CPU Usage, 60 minute avg: 4.41% Process Data Segment Size via sbrk( ): 342739 KB Maximum Resident Size: 345612 KB Page faults with physical i/o: 65375
You'll see a section called Memory usage for squid via mstats( ) if your system has the mstats( ) function. In particular, you'll have this function if the GNU malloc library (libgnumalloc.a) is installed. Squid reports two statistics from mstats( ): Memory usage for squid via mstats( ): Total space in arena: 415116 KB Total free: 129649 KB 31%
The Memory accounted for section contains a few tidbits about Squid's internal memory management techniques: Memory accounted for: Total accounted: 228155 KB memPoolAlloc calls:<PHONE_NUMBER> memPoolFree calls:<PHONE_NUMBER>
The File descriptor usage section shows how many file descriptors are available to Squid and how many are in use: File descriptor usage for squid: Maximum number of file descriptors: 7372 Largest file desc currently in use: 151 Number of file desc currently in use: 105 Files queued for open: 0 Available number of file descriptors: 7267 Reserved number of file descriptors: 100 Store Disk files open: 0
The Internal Data Structures section gives a quick overview of how many objects are in the cache and how many are on disk or in memory. You can find more detail about Squid's data structure allocations in the mem page (see Section <IP_ADDRESS>). This section has a few stats: Internal Data Structures: 2873586 StoreEntries 1336 StoreEntries with MemObjects 1302 Hot Object Cache Items 2873375 on-disk objects
<IP_ADDRESS> filedescriptors: Process File Descriptor AllocationThis page displays a table of all file descriptors currently opened by Squid. It looks like this: File Type Tout Nread * Nwrite * Remote Address Description ---- ------ ---- -------- -------- ----------------- ------------------------------ 3 File 0 0 0 /usr/local/squid/logs/cache.log 6 File 0 0 2083739 /usr/local/squid/logs/access.log 12 Pipe 0 0 0 unlinkd -> squid 13 File 0 0 2485913 /usr/local/squid/logs/store.log 15 Pipe 0 0 0 squid -> unlinkd 16 Socket 24 220853* 1924 <IP_ADDRESS>.80 http://downloads.mp3.com/ 18 Pipe 0 0 0 squid -> diskd 19 Socket 179 476* 1747 <IP_ADDRESS>.4171 http://ads.vesperexchange.com/ 21 Pipe 0 0 0 squid -> diskd 22 Socket 20 158783* 998 <IP_ADDRESS>.80 http://home.hanmir.com/a 24 Pipe 0 0 0 squid -> diskd 25 Socket 1 0 0* <IP_ADDRESS>.80 http://home.hanmir.com/b 26 Socket 0 9048307* 1578290 .0 DNS Socket 27 Pipe 0 0 0 squid -> diskd 28 Socket 0 0 0* <IP_ADDRESS>.80 http://updates.hotbar.com/ 29 Socket 0 0* 0 .0 HTTP Socket 30 Pipe 0 0 0 squid -> diskd 31 Socket 0 93 1126 <IP_ADDRESS>.3434 ncsa_auth #1 32 Socket 0 3 31 <IP_ADDRESS>.3438 ncsa_auth #3 33 Socket 0 0 0 <IP_ADDRESS>.3440 ncsa_auth #4 34 Socket 164 8835* 1070222* <IP_ADDRESS>.2201 http://www.eyyubyaqubov.com/ 35 Socket 177 6137* 249899* <IP_ADDRESS>.3044 http://files10.rarlab.com/ 36 Socket 0 0 0 <IP_ADDRESS>.3442 ncsa_auth #5 37 Socket 7 158783* 774 <IP_ADDRESS>.80 http://home.hanmir.com/c 38 Socket 166 1000* 148415* <IP_ADDRESS>.5787 http://home.hanmir.com/d The table has seven columns:
By default, the File Descriptor page isn't password-protected. However, you may want to give it a password because it contains some sensitive and, perhaps, personally identifiable information. <IP_ADDRESS> objects: All Cache ObjectsRequesting this page results in a list of all objects in the cache. Be careful with this page because it can be extremely long. Furthermore, it contains low-level information that is probably useful only to developers. For each cached object, Squid prints a sequence of lines, most of which look like this: KEY FF1F6736BCC167A4C3F93275A126C5F5 STORE_OK NOT_IN_MEMORY SWAPOUT_DONE PING_NONE CACHABLE,DISPATCHED,VALIDATED LV:1020824321 LU:1020824671 LM:1020821288 EX:-1 0 locks, 0 clients, 1 refs Swap Dir 0, File 0X010AEE The first line shows the cache key—a 128-bit MD5 checksum of the URI. The same MD5 checksum appears in store.log and in the metadata at the beginning of each response cached on disk. The second line shows four state variables of the StoreEntry data structure: store_status, mem_status, swap_status, and ping_status. Refer to the Squid source code if you'd like more information about them. The third line is a list of the StoreEntry flags that are set. Search the source code for e->flags for more information. The fourth line shows the values of four timestamps: last-validation, last-use, last-modification, and expiration. The last-modification and expiration timestamps are taken from the origin server's HTTP response. The others are maintained by Squid. The fifth line shows a few counters: locks, clients, and references. An entry with locks can't be removed. The clients counter shows how many clients are currently receiving data for this object. The refs counter shows how many times the object has been requested. The sixth line shows the object's index to the on-disk storage. Each object has a 7-bit swap directory index and a 25-bit file number. Each storage scheme has a function to map these numbers into pathnames. <IP_ADDRESS> vm_objects: In-Memory and In-Transit ObjectsThis page is similar to All Cache Objects, except that it displays only objects that have a MemObject data structure. In other words, objects that are currently being requested or are stored in the memory cache. These objects are displayed like this: KEY 5107D49BA7F9C6BA9559E006D6DDC4B2 GET http://www.rpgplanet.com/ac2hq/cartography/dynamic/LinvakMassif.jpg STORE_PENDING NOT_IN_MEMORY SWAPOUT_WRITING PING_DONE CACHABLE,DISPATCHED,VALIDATED LV:1043286120 LU:1043286122 LM:1036015230 EX:-1 4 locks, 1 clients, 1 refs Swap Dir 1, File 00X31BD9 inmem_lo: 184784 inmem_hi: 229840 swapout: 229376 bytes queued swapout: 229509 bytes written Client #0, 1533a1018 copy_offset: 217552 seen_offset: 217552 copy_size: 4096 flags: As you can see, many of the lines are the same. However, the in-memory objects have a few additional lines. Directly following the cache key (MD5 checksum), Squid prints the request method and URI. The inmem_lo and inmem_hi lines are byte offsets of the HTTP reply. They indicate the section of object data currently in memory. In most cases, the difference between these two should be less than the value of the maximum_object_size_in_memory directive. The swapout: bytes queued line shows the offset for how many bytes have been given to the storage layer for writing. For objects in the SWAPOUT_DONE state, this value is the same as the object size. If the state is SWAPOUT_WRITING, Squid also shows the bytes written line, which indicates how many bytes have been successfully stored on disk. If one or more clients are currently receiving the response, you'll see a section for each of them (Client #0 in this example). For each client, Squid reports another pair of offset values. The first, copy_offset, is the starting point for the last time the client-side asked for data from the storage system. The second, seen_offset, is the point at which the response data has been sent to the client. Note that copy_offset is always greater than or equal to seen_offset. The copy_size indicates the maximum amount of data the client can receive from the storage system. <IP_ADDRESS> openfd_objects: Objects with Swapout Files OpenThe format of this page is the same as for In-Memory and In-Transit Objects. The objects reported on this page should all be in the SWAPOUT_WRITING state. The page is primarily useful to developers when trying to track down file-descriptor leaks. <IP_ADDRESS> io: Server-Side Network read( ) Size HistogramsThis page displays a histogram for each of the following four server-side protocols: HTTP, FTP, Gopher, and WAIS. The histograms show how many bytes each read( ) call received. The information is primarily useful to developers for tuning buffer sizes and other aspects of the source code. The bins of the histogram are logarithmic to accommodate the large scale of read sizes. Here is an example: HTTP I/O number of reads: 9016088 Read Histogram: 1- 1: 3082 0% 2- 2: 583 0% 3- 4: 905 0% 5- 8: 2666 0% 9- 16: 16690 0% 17- 32: 88046 1% 33- 64: 19712 0% 65- 128: 116655 1% 129- 256: 749259 8% 257- 512: 633075 7% 513- 1024: 903145 10% 1025- 2048: 3664862 41% 2049- 4096: 1643747 18% 4097- 8192: 789796 9% 8193-16384: 99476 1% 16385-32768: 30059 0% In this case, you can see that the bin for 1025-2048 bytes is the most popular. When reading from an HTTP server, Squid got between 1025 and 2048 bytes per read 41% of the time. <IP_ADDRESS> counters: Traffic and Resource CountersSquid maintains a data structure of counters. Actually, it is an array of counters. Squid shifts the array every 60 seconds and calculates 1-, 5-, and 60-minute averages from this array. This page is simply a dump of the current counter values in a format more suitable for computer processing than for reading by humans. The counters are as follows:
<IP_ADDRESS> peer_select: Peer Selection AlgorithmsThis page contains a lot of low-level detail about cache digests that I won't discuss. Most of the numbers are meaningful only to the developers that originally wrote the Cache Digest implementation. However, at the end of this page is a little table that compares Algorithm usage: Algorithm usage: Cache Digest: 27 ( 24%) Icp: 84 ( 76%) Total: 111 (100%) In this example, you can see that Squid sent 111 requests to one of its neighbors: 27 are due to Cache Digests and 84 are due to ICP. In this context, ICP also includes HTCP. <IP_ADDRESS> digest_stats: Cache Digest and ICP BlobThis page is actually just a concatenation of the following other cache manager pages:
Its only purpose is to enable developers to take a snapshot of a number of statistics with a single request. <IP_ADDRESS> 5min: 5 Minute Average of CountersThis page shows a five-minute average of the data in the Traffic and Resource Counters page. In addition to the counters mentioned in Section <IP_ADDRESS>, this page also contains the following values:
<IP_ADDRESS> 60min: 60 Minute Average of CountersThis page shows a 60-minute average of the data in the Traffic and Resource Counters page. The descriptions are identical to those for the 5 Minute Average of Counters page, except the measurements are taken over one hour. <IP_ADDRESS> utilization: Cache UtilizationThis page displays averages of the counters (see Traffic and Resource Counters and 5 Minute Average of Counters) over various time spans. The same values are reported for 5-minute, 15-minute, 1-hour, 8-hour, 1-day, and 3-day intervals. This page, with a poorly chosen name, exists primarily so that developers can take a quick snapshot of statistics for testing purposes. <IP_ADDRESS> histograms: Full Histogram CountsThis page displays the current histogram values (since Squid was started) for a number of measurements:
These are the same measurements described in Section <IP_ADDRESS>, except that here Squid gives the full histogram, instead of the mean or median. Depending on the type of histogram, you may see two or three columns. The first column is the bin number and lower bound on the bin value. The second column is the number of counts for that bin. The optional third column is the number of counts divided by the "size" of the bin. The last column is probably only interesting for log-based histograms, in which the bin size isn't constant. <IP_ADDRESS> active_requests: Client-Side Active RequestsThis page shows a list of currently active client-side requests. The list is sorted starting with the most recent, and ending with the oldest requests. The information given here is primarily useful to developers. A typical entry looks like this: Connection: 0x84ecd10 FD 132, read 1273, wrote 12182 FD desc: http://www.squid-cache.org/Doc/FAQ/FAQ.html in: buf 0xa063000, offset 0, size 4096 peer: <IP_ADDRESS>:1058 me: <IP_ADDRESS>:3128 nrequests: 3 defer: n 0, until 0 uri http://www.squid-cache.org/Doc/FAQ/FAQ.html log_type TCP_MISS out.offset 0, out.size 0 req_sz 392 entry 0x960c680/3B49762ABF444D80B6465552F6CFAD4C old_entry 0x0/N/A start<PHONE_NUMBER>.669955 (2.240814 seconds ago)
<IP_ADDRESS> store_digest: Store DigestThis page is available only with the ./configure —enable-cache-digests option. It displays a few statistics about Squid's own cache digest. It looks like this: store digest: size: 620307 bytes entries: count: 324806 capacity: 992490 util: 33% deletion attempts: 0 bits: per entry: 5 on: 1141065 capacity: 4962456 util: 23% bit-seq: count: 1757902 avg.len: 2.82 added: 324806 rejected: 611203 ( 65.30 %) del-ed: 0 collisions: on add: 0.08 % on rej: 0.07 %
<IP_ADDRESS> storedir: Store Directory StatsThis page displays some statistics from the storage system. First, you'll see a few global values. For example: Store Directory Statistics: Store Entries : 2873564 Maximum Swap Size : 46080000 KB Current Store Swap Size: 41461672 KB Current Capacity : 90% used, 10% free
Next, you'll see a section for each cache_dir. It looks something like this: Store Directory #1 (diskd): /cache1 FS Block Size 1024 Bytes First level subdirectories: 16 Second level subdirectories: 64 Maximum Size: 15360000 KB Current Size: 13823996 KB Percent Used: 90.00% Filemap bits in use: 958439 of 2097152 (46%) Filesystem Space in use: 14030485/17370434 KB (81%) Filesystem Inodes in use: 959440/4340990 (22%) Flags: SELECTED Pending operations: 0 Removal policy: lru LRU reference age: 23.63 days
The next few lines are actually storage scheme-dependent. For the most part, ufs, aufs, and diskd are very similar and all report the same statistics.
That's the end of the scheme-specific data. The remaining lines are specific to the cache_dir replacement algorithm:
<IP_ADDRESS> store_check_cachable_stats: storeCheckCachable( ) StatsThis page displays a table of counters from the storeCheckCachable( ) function. It is called for most responses, just before Squid attempts to open a disk file for writing.
The table includes the following lines:
In some versions of Squid, this counter is always zero because storeReleaseRequest( ) is always called if the response size doesn't match the expected content length.
<IP_ADDRESS> store_io: Store IO Interface StatsThis short table contains four lines related to allocating disk storage for a new response. For example: Store IO Interface Stats create.calls 2825670 create.select_fail 0 create.create_fail 0 create.success 2825670
<IP_ADDRESS> pconn: Persistent Connection Utilization HistogramsThis page displays two histograms. The first is for client-side persistent connection usage. For example: Client-side persistent connection counts: req/ conn count ---- --------- 0 74292 1 14362705 2 3545955 3 2068486 4 1411423 5 1030023 6 778722 7 603649 8 474592 9 376154 10 301396 On the left is the number of requests per connection. On the right is the number of times a client connection had that many requests. Most likely, you'll see that one request/connection has the highest count and that the counts decrease as the number of requests/connection increases. The second table has the same information, but for server-side HTTP connections. You should see the same sort of pattern here, with one request/connection having the highest count. <IP_ADDRESS> refresh: Refresh Algorithm StatisticsThe refresh page shows a few tables relating to the freshness of cached objects. Internally, Squid keeps track of the way different modules use the refresh functions. The first table shows how many calls each module has made. The really interesting data is contained in the remaining tables, however. The HTTP histogram shows the breakdown of freshness checks for client HTTP requests. For example: HTTP histogram: Count %Total Category 0 0.00 Fresh: request max-stale wildcard 0 0.00 Fresh: request max-stale value 173984 9.76 Fresh: expires time not reached 462757 25.97 Fresh: refresh_pattern last-mod factor percentage 42 0.00 Fresh: refresh_pattern min value 0 0.00 Fresh: refresh_pattern override expires 0 0.00 Fresh: refresh_pattern override lastmod 5521 0.31 Stale: response has must-revalidate 0 0.00 Stale: changed reload into IMS 0 0.00 Stale: request has no-cache directive 470912 26.43 Stale: age exceeds request max-age value 455073 25.54 Stale: expires time reached 65612 3.68 Stale: refresh_pattern max age rule 144706 8.12 Stale: refresh_pattern last-mod factor percentage 3274 0.18 Stale: by default 1781881 100.00 TOTAL Note, the rules aren't necessarily evaluated in the order in which they appear in the table. Here's what each line means:
Following the HTTP histogram, you'll see the same data for ICP, HTCP, Cache Digests, and On Store. The On Store table represents freshness checks for responses that are coming into Squid's cache (i.e., cachable misses). Note, however, that Squid does store stale responses (as long as they have a cache validator). Don't be alarmed if you see some stale responses in the On Store histogram. <IP_ADDRESS> delay: Delay Pool LevelsThis page displays the Delay Pool statistics. Squid has three classes of pools (1, 2, 3) and three types of buckets (aggregate, individual, and network). A class 1 pool has only an aggregate bucket, a class 2 pool has both aggregate and individual, and a class 3 pool has all three. An aggregate bucket looks like this: Aggregate: Max: 16384 Restore: 4096 Current: 6144 The values are all in bytes. Max is the size of the bucket, which is the number of bytes the bucket can hold. Restore is the number of bytes added to the bucket each second. Current is the number of bytes currently in the bucket. If nobody uses the bytes, the bucket fills until it reaches the maximum size. An individual bucket is almost the same: Individual: Max: 20000 Restore: 5000 Current: 1:18760 9:4475 14:20000 The only difference is that the Current line displays a number of different values, one for each host number. The host number is defined as the last octet of an IPv4 address. In this example, the host numbers are 1, 9, and 14. In a class 2 delay pool, the host numbers from different networks share the same bucket. For example, <IP_ADDRESS> and <IP_ADDRESS> both share the bucket for host number 1. In a class 3 pool, however, each network number (third octet) has its own array of individual buckets. Thus, for a class 3 pool, the individual buckets appear this way: Individual: Max: 20000 Rate: 5000 Current [Network 0]: 1:12000 Current [Network 44]: 1:17000 A network bucket (for class 3 pools only) is similar as well: Network: Max: 30000 Rate: 15000 Current: 0:3912 7:30000 In this case, the Current line shows the current level for each network number (third octet). See Appendix C for more information about Delay Pools. <IP_ADDRESS> forward: Request Forwarding StatisticsThe table on this page shows how many attempts were made to forward each request, with their results. Upon receiving some status codes, Squid gives up immediately. For others, however, Squid keeps trying. Each row of the table is a different HTTP status code (200, 401, 404, etc.). Each column is the number of forwarding attempts. The value in each cell is how many requests were forwarded that many times, resulting in the corresponding status code. This information helps developers understand whether or not it makes sense to retry a request after receiving certain types of responses. Here is an example: Status try#1 try#2 try#3 try#4 try#5 try#6 try#7 try#8 try#9 try#10 0 1 0 0 0 0 0 0 0 0 0<PHONE_NUMBER><PHONE_NUMBER>5 29002 18242 12097 8191 6080 4490 6140 201 57 0 0 0 0 0 0 0 0 0 202 162 0 0 0 0 0 0 0 0 0 204 1321 11 0 0 0 0 0 0 0 0 206 624288 453 25 9 4 3 0 1 0 0 207 147 0 0 0 0 0 0 0 0 0 300 23 0 0 0 0 0 0 0 0 0 301 23500 25 2 0 0 0 1 0 0 0 302<PHONE_NUMBER> 153 26 6 4 2 3 0 1 303 101 1 0 0 0 0 0 0 0 0 304<PHONE_NUMBER> 125 21 7 8 8 5 3 2 307 7 0 0 0 0 0 0 0 0 0 400 529 1 0 0 0 0 0 0 0 0 401 1559 0 0 0 0 0 0 0 0 0 403 5098 30 1 1 0 0 0 0 0 0 404 100800 216 25 6 7 1 2 4 1 5 405 1 0 0 0 0 0 0 0 0 0 ... A value of 29,002 in the cell under try#4 and in the row for status 200 means that there were 29,002 times when Squid finally got a successful response after 4 forwarding attempts. If you look at the table, you may see some unknown status codes. Squid keeps track of all status codes up to 600, even those it doesn't know about. See Table 13-1 for the list of codes that Squid does know about. <IP_ADDRESS> client_list: Cache Client ListThe cache client list shows a handful of statistics for each client IP address accessing Squid, which looks like this: Address: <IP_ADDRESS> Name: <IP_ADDRESS> Currently established connections: 0 ICP Requests 59000 UDP_HIT 1609 3% UDP_MISS 57388 97% UDP_INVALID 3 0% HTTP Requests 11281 TCP_HIT 656 6% TCP_MISS 3464 31% TCP_REFRESH_HIT 4477 40% TCP_REFRESH_MISS 767 7% TCP_CLIENT_REFRESH_M 397 4% TCP_IMS_HIT 1082 10% TCP_SWAPFAIL_MISS 7 0% TCP_NEGATIVE_HIT 13 0% TCP_MEM_HIT 418 4% The Address line, obviously, shows the client's IP address. Name is the same, unless you have log_fqdn enabled, and the DNS reports a name for the address. The Currently established connections line shows how many HTTP connections are currently open between the client and Squid. If the client has sent any ICP queries, you'll see a breakdown of the results here. In this example, only 3% of this client's ICP queries were hits. Note, this page doesn't currently include HTCP result statistics. Finally, you'll see a breakdown of HTTP request result codes. The client database consumes a fair amount of memory, especially if you have a large number of client IP addresses accessing Squid. You can disable the database entirely, thus conserving memory, with the client_db directive. Also note that there is no way to clear the counters or to remove entries while Squid is running. <IP_ADDRESS> netdb: Network Measurement DatabaseThis page is available only with the ./configure —enable-icmp option (see Section 10.5). On this page you'll find quite a lot of IP addresses, hostnames, packet counters, and RTT values. It looks something like this: Network DB Statistics: Network recv/sent RTT Hops Hostnames <IP_ADDRESS> 7/ 7 12.7 8.6 onlinebooks.library.upenn.edu www.library.upenn.edu digital.library.upenn.edu rtp.us.ircache.net 17.0 11.0 sj.us.ircache.net 71.0 17.3 <IP_ADDRESS> 4/ 4 12.8 10.0 adbuyer3.lycos.com rtp.us.ircache.net 20.6 15.0 sj.us.ircache.net 77.6 15.0 <IP_ADDRESS> 17/ 17 12.8 9.0 www.originlab.com sj.us.ircache.net 80.0 12.0 <IP_ADDRESS> 23/ 23 12.8 11.7 www6.tomshardware.com www.guestbook.nu rtp.us.ircache.net 34.9 15.1 sj.us.ircache.net 73.9 14.7 Each /24 network is listed, in order of increasing round-trip time. You can see how many ICMP pings have been sent and received, the average RTT, and the estimated router hop-count. The Hostnames field shows the hostnames that resolve to addresses within the /24 network. If Squid has ICMP measurements from its neighbors for the network, those are printed as well. In this example, the local cache is closer to all the networks than its neighbors (rtp.us.ircache.net and sj.us.ircache.net). <IP_ADDRESS> asndb: AS Number DatabaseAlthough this page is always available, it contains interesting data only if you are using one of the Autonomous System (AS) ACLs, such as src_as or dst_as. When you use an AS-based ACL, Squid queries the Routing Arbiter database (whois.ra.net) to discover the IP networks associated with the AS number. The results of those queries are displayed on this page. The output looks like this: Address AS Numbers <IP_ADDRESS>/16 7 <IP_ADDRESS>/16 7 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 5637 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 7 <IP_ADDRESS>/24 7 <IP_ADDRESS> carp: CARP InformationThis page is available only with the ./configure —enable-carp option and if you have some CARP parents configured. Squid displays a table of all CARP parents, which looks like this: Hostname Hash Multiplier Factor Actual bo1.us.ircache.net f142425b 0.894427 0.400000 0.527950 bo2.us.ircache.net 12180f04 1.118034 0.600000 0.472050 Hash is the neighbor's hash value from the CARP algorithm. Multiplier is another value used by the algorithm. Factor is taken from the carp-load-factor option on the cache_dir line in squid.conf. Actual is the actual distribution of requests among the CARP parents. Ideally, it should match the Factor value. <IP_ADDRESS> server_list: Peer Cache StatisticsThis page displays various counters and statistics for your neighbor caches. For example: Sibling : pa.us.ircache.net/3128/4827 Flags : htcp Address[0] : <IP_ADDRESS> Status : Up AVG RTT : 14 msec OPEN CONNS : 19 LAST QUERY : 4 seconds ago LAST REPLY : 4 seconds ago PINGS SENT : 9119 PINGS ACKED: 9115 100% FETCHES : 109 1% IGNORED : 9114 100% Histogram of PINGS ACKED: Misses 9114 100% Hits 1 0% keep-alive ratio: 100%
<IP_ADDRESS> non_peers: List of Unknown Sites Sending ICP messagesThis page shows a list of clients that send unauthorized ICP (but not HTCP) queries. The list is the same format as the Cache Client List page. 14.2.2 Cache Manager Access ControlsThe cache manager interface provides a lot of information. Much of it is sensitive and should be kept private. For example, the Cache Client List reveals the IP addresses of users, the Process Filedescriptor Allocation page shows URIs currently being requested, and the Current Squid Configuration displays the values from squid.conf, including passwords and access control rules. To keep unwanted visitors from browsing the cache manager pages, you must carefully configure access to it. <IP_ADDRESS> http_accessAll cache manager requests use the pseudo-protocol scheme cache_object. The best way to protect the cache manager is restrict the IP addresses allowed to make cache_object requests. The default squid.conf contains these lines: acl Manager proto cache_object acl Localhost src <IP_ADDRESS>/<IP_ADDRESS> http_access allow Manager Localhost http_access deny Manager Thus, cache manager requests from the local host (<IP_ADDRESS>) are allowed, but all others are denied. If you have additional trusted hosts, you may want to add them to the access rules also. Make sure these lines are at the top of your http_access rules. <IP_ADDRESS> cachemgr_passwdYou may also want to modify the default cachemgr_passwd settings. Some of the cache manager pages require a password, so you won't be able to view those until you add one. For example, if you want to use the Current Squid Configuration page, you must assign it a password: cachemgr_passwd JeckCy config You can have a number of different passwords, but each action may have only one password. You may want to use a different password for less sensitive pages: cachemgr_passwd byDroth filedescriptors client_list netdb To disable a cache manager action, use disable as the password: cachemgr_passwd disable netdb To enable the sensitive actions without requiring a password, use none: cachemgr_passwd none offline_toggle If you want to give the same password to all actions, use the keyword all: cachemgr_passwd Knoujush all When using the command-line cache manager interface (e.g., squidclient), put an @ sign and the password after the action name. For example: squidclient mgr:objects@byDroth | less Note that cache manager passwords aren't printed when you request the Current Squid Configuration page (see Section <IP_ADDRESS>). <IP_ADDRESS> cachemgr.cgiIf you use cachemgr.cgi, the IP address of your HTTP server must be able to make cache manager requests to Squid. This opens up a back-door security hole. Anyone who can execute the CGI program on your server will be able to view the cache manager pages. The passwords described earlier can help, but you may also want to install access controls on your HTTP server so that only certain people can execute cachemgr.cgi. The main cachemgr.cgi page has a form with Username and Password fields. The username is purely informational. If you have multiple administrators in your organization, each person can enter their own name for auditing purposes. If you leave the password field blank, the password-protected pages are disabled. Entering a password activates links for those pages. cachemgr.cgi is stateless, so the password must be included as a URI parameter in links. Furthermore, the password encoding scheme isn't very sophisticated and trivial to break. Because many applications (such as Squid!) log the URIs of HTTP requests, your cache-manager password may be logged or even observed by an untrusted third party. If you really want to keep your cache manager passwords secret, never use them with cachemgr.cgi or from any remote system. 14.2.3 Reasons to Dislike the Cache ManagerThe cache manager interface leaves much to be desired. It has a very unpolished feel. Novice administrators will probably find it difficult to use and understand. One of the first problems you might notice is that the menu (or table of contents) is unorganized. There is no logical order or grouping. The first items in the list provide low-level information primarily meant for developers. Currently, the order is determined by the initialization sequence in the source code. The output is often ugly. The cachemgr.cgi program renders very bland-looking HTML pages. There are no icons or graphics of any kind. Furthermore, many of the pages are simply presented as unformatted text. cachemgr.cgi doesn't do much more than format tab-delimited lines as HTML tables and put <A> tags around some URIs. Some of the cache manager pages are structured so that the output can be easily parsed by computer programs, rather than humans. By today's standards, the cache manager has very weak security. You are essentially forced to use address-based controls and cleartext passwords. If you allow cache manager requests only from localhost, and your system security is good, you'll be relatively safe. 14.2.4 Squid-RRDI personally use the cache manager to populate a number of RRDTool databases (http://www.rrdtool.com/). RRDTool is nice package for storing and displaying time-series data. It allows you to archive data at different time scales (e.g., days, weeks, months, years) in a database that doesn't grow in size over time. I use a Perl script that runs every five minutes from cron. It issues cache manager requests for a number of pages and extracts the values that I am interested in. These values are stored in the RRD files. RRDTool also generates nice-looking graphs, from either a CGI script or standalone program. I use the CGI program and check the graphs at least daily. See Figure 14-2 for some samples from one of my own Squid boxes. Figure 14-2. Some sample RRD graphs from RRDTool and cache manager dataYou can find my scripts and instructions for integrating the cache manager and RRDTool at http://www.squid-cache.org/~wessels/squid-rrd/. |
| < Day Day Up > |


My Name is Matthew Grimes, I am 24 years old, and I live in Salt Lake City Utah. I am currently taking classes for web development, and this website is one of my projects. I love working with computers, and doing anything related ot visual design. I have a cat named Dexter, and my hobbies iclude reading, DnD and gaming.


nips nips2007 nips2007-52 nips2007-52-reference knowledge-graph by maker-knowledge-mining
Source: pdf
Author: Judy Goldsmith, Martin Mundhenk
Abstract: It is known that determinining whether a DEC-POMDP, namely, a cooperative partially observable stochastic game (POSG), has a cooperative strategy with positive expected reward is complete for NEXP. It was not known until now how cooperation affected that complexity. We show that, for competitive POSGs, the complexity of determining whether one team has a positive-expected-reward strategy is complete for NEXPNP .
[1] Daniel S. Bernstein, Robert Givan, Neil Immerman, and Shlomo Zilberstein. The complexity of decentralized control of Markov decision processes. Math. Oper. Res., 27(4):819–840, 2002.
[2] E. Hansen, D. Bernstein, and S. Zilberstein. Dynamic programming for partially observable stochastic games. In Proceedings of the Nineteenth National Conference on Artiﬁcial Intelligence (AAAI-04), pages 709–715, 2004.
[3] Hao Wang. Proving theorems by pattern recognition II. Bell Systems Technical Journal, 40:1– 42, 1961.
[4] M. Savelsbergh and P. van Emde Boas. Bounded tiling, an alternative to satisﬁability. In Gerd Wechsung, editor, 2nd Frege Conference, volume 20 of Mathematische Forschung, pages 354– 363. Akademie Verlag, Berlin, 1984.
[5] C.H. Papadimitriou and J.N. Tsitsiklis. The complexity of Markov decision processes. Mathematics of Operations Research, 12(3):441–450, 1987.
[6] Martin Mundhenk, Judy Goldsmith, Christopher Lusena, and Eric Allender. Complexity results for ﬁnite-horizon Markov decision process problems. Journal of the ACM, 47(4):681–720, 2000. 8


{% extends 'layouts/master.html' %} {% block script %} {% endblock %} {% block body %}
You can download the script ready to use right here :
Download the script ready to use
If you're facing with any issue, you can use our live chat in the lower right corner! We'll enjoy answering :)


 Come back after your skills have increased.
(Only characters who are level 80 or higher may undertake this quest.)


Will your investment property pass the ‘test’ next year?
Since we last spoke to you in March 2017, there’s been a change in government – and subsequently, a lot more chatter around the state of New Zealand’s rental housing stock. The passing of the Healthy Homes Bill in December 2017 means there are changes coming, as soon as next year, which will require landlords to guarantee any new tenancy from July 1, 2019 must be either properly insulated or contain a heating source able to make the home warm and dry. All tenancies must meet the new standards by July 1, 2024.
The issue with this is heating a home won’t make it dry. Without properly-designed and installed whole house ventilation, dampness and mould can continue to grow in a home, despite a landlord’s best efforts in heating and insulating the property.
We’re hearing of more and more Kiwi families struggling through winter, their houses riddled with mould which severely affects their health. There’s been a lot of talk about tenants not being able to afford the heating their landlords are installing for them as well – a factor that could be reversed if the house was properly ventilated and insulated – as drier homes can be easier to heat.
Take the onus away from your tenants - it's an investment
If you’re a landlord, especially in lower socio-economic areas, do the right thing by addressing the three key factors needed to create a healthy home; insulation, heating and whole house ventilation. This will help bring electricity costs down so tenants will actually use their heating, while also keeping your investment free from damage caused by dampness and mould. And, most importantly, it will help keep your tenants healthy through winter.
Tenants are also likely to stay longer in a rental property that’s warm and doesn’t compromise their health, reducing the costs of high tenant turnover – not to mention the fact they’ll respect the home more. Those in a damp/cold home are more likely to suffer avoidable illness, often resulting in unplanned medical bills and time off work. Unexpected financial burdens like this increase the risk of missed rent payments.
Although it’s likely you may need to increase the rent to cover these investments, ask yourself whether your tenants would rather live in a mouldy, unhealthy dwelling which is slightly cheaper or a healthy, warm and dry one that will improve their lives and decrease their bills elsewhere such as cutting down on doctors’ visits. Improving your dwelling makes it a more desirable prospect, tenants pay more, a purchaser will pay more if you decide to sell, and you'll see less ongoing maintenance costs from dampness, mould and other issues.
The Solution
The DVS EC Automatic Ventilation System uses positive pressure technology to push out the stale, unhealthy, moisture-laden air in a home.
Simplicity is the key - your tenants don't need to do a thing because the DVS system takes care of itself. Power consumption is only $1.50 per month for an average home so there’s no need to worry about high energy bills, and you can relax knowing your investment property will stay dry and fresh all year round.
We have a great deal for Landlords!
10% off the regular price
or $26.87 per week*
or $29.37 per week*
To take advantage of this offer, call us on 0800 387 387 or visit our website to arrange a free consultation for your rental properties.
"At the end of the day, a healthy home means happy tenants, and happy tenants means less hassle for you!"


Overview QA4SM
The Quality Assurance for Soil Moisture (QA4SM) service provides the user with:
- An easy-to-use interface for comparing satellite soil moisture data against land surface models and the international soil moisture network
- A traceble and consistent methodology for all comparisons
- Various filtering and scaling options to assess the impact of these on the validation results
- Traceable validation results in netCDF format and as visualisations (graphs and maps)
QA4SM is supported by the Austrian Space Application Programme.
News
{{ news_text |safe }}Datasets and Settings
Allows specification of input datasets and settings for your validation
Results
Provides a list of all validation results
Download and Visualize
Allows download of validation results in netCDF format and as graphics


fifthwave Issue Tracker
Upcoming Releases
| 0.3 | 83% complete |
| 15 / 18 issues. See issues | |
| 0.4 | 0% complete |
| 0 / 13 issues. See issues |
Past Releases
| 0.2 | on 2011-02-09 |
Unassigned Issues
2 unassigned issues (2 open).
Open Issues by component
| fifthwave | 2 open issues |
| fifthwave.py | 8 open issues |
| fileutils.py | 0 open issues |
| flightdeck.py | 6 open issues |
| licread.py | 0 open issues |
| sshmods.py | 1 open issues |
| sshsge.py | 1 open issues |
| verify.py | 0 open issues |
Recent Activity
| 2011-12-05 | Calculte celerity over multiple steps. | bugfix | created |
| 2011-12-05 | Add RMS elevation metric. | feature | created |
| 2011-11-28 | Analysis does not work after simultion | bugfix | created |
| 2011-11-23 | Improve report_convergence to aggregate metrics | feature | closed with disposition fixed |
| 2011-11-23 | Add multiple wave analysis | feature | closed with disposition fixed |
| 2011-09-15 | Improve report_convergence to aggregate metrics | feature | created |
| 2011-09-15 | Allow separate computation and analysis | feature | closed with disposition fixed |
| 2011-09-15 | Allow separate computation and analysis | feature | created |
| 2011-09-15 | ZeroDivisionError is asymptotic ratio | bugfix | closed with disposition fixed |
| 2011-09-15 | fifthwave can't operate on one output file | bugfix | closed with disposition wontfix |


{% extends 'base.html' %} {% load bootstrap4 %} {% block team_content %}
Deleting this Forum will also delete all {{ object.name }} Threads and Comments, and their related data!


Post Information
Uploaded by
Published
Click the link to copy it to your clipboard.
Statistics
comments
views
Comments
You must be logged in to leave a comment,
login
or
create
an account.
Submit
Comments


‘Star Wars: The Rise of Skywalker’ Character Posters Might as Well Be Bubble Gum Trading Cards
by Ethan AndertonThe posters of the Star Wars franchise have been some of the best that studio marketing has to offer. Much of that has to do with the beautiful illustrations of Drew Struzan, and in recent years, fans have been missing his artistic touch. It’s not that the posters for the new Star Wars trilogy have been terrible, but they feel like shiny Photoshop jobs as opposed to works of art. Unfortunately, a new batch of Star Wars: The Rise of Skywalker character posters are among the worst Star Wars posters we’ve seen.
Star Wars: The Rise of Skywalker Character Posters
The posters for Rey and Kylo Ren show exactly what’s wrong with these posters. Each of these characters look so glossy and touched up, they might as well be in a Sports Illustrated Swimsuit Edition magazine. The shine on Kylo Ren’s helmet looks completely fake. And pretty much the entire roster of posters resemble the kind of promotional posters kids might see for sale at Walmart.
Lando Calrissian gets his own poster, but much like the Kylo Ren poster, his wardrobe doesn’t allow for much color contrast. While the yellow of his shirt pops, the cape only adds to the darkness of space behind him. Couldn’t they have done different backgrounds for each character poster? Even a generic planet background would have been better. But these are just lazy.
Here we have Finn and Jannah, who will be spending some time together in The Rise of Skywalker. Finn looks like he’s posing for a Space Jam basketball card while that photo of Jannah appears to be a publicity still that was previously released and reworked into a character poster. Again, these are just completely uninspired.
Poe Dameron and Zorri Bliss are both armed and ready for action. The only redeeming thing about this batch of posters is that we get a better look at the weapons that Zorri Bliss will be wielding in the movie. Otherwise, the Poe Dameron poster again shows why the black space background doesn’t work, making the blaster in his hand look terrible.
Oh hey, there’s Rose! And she’s looking pretty armed and dangerous in this poster. It’s just a shame that again her wardrobe and weapons barely pop out of the space background.
Finally, Disney really wanted to milk character posters for all they’re worth, so they gave all four of the droids their own posters. They really couldn’t team up BB-8 with D-O or C-3PO with R2-D2? That would have made much more sense and probably would have made for slightly better image composition.
Hopefully there will be better poster art arriving before Star Wars: The Rise of Skywalker opens on December 20, 2019.


I have two years of professional experience as a software developer at Samsung R&D, India. I am passionate about leveraging my technical skills to make an impact on the society. Currently, I am pursuing a Masters in Computer Science at the University of Florida.
GPA: 3.72/4.00
GPA: 7.87/10.0
Implemented a large scale peer to peer system that performs distributed key lookups and generates routing tables on 5000+ nodes in minimal time using Elixir.
Worked in a team of two to develop an application for simulating Gossip protocol (an information dissemination model) in a scalable distributed system with different network topologies using Elixir.
Used Natural Language Toolkit (NLTK) library to classify news articles as positive and negative with 89% accuracy. Preprocessed the data and analyzed the frequency distribution of the feature words using Python.
Worked with Dr. Christopher Brooks (Professor, University of Michigan) in improving the course 'Introduction to Data Science in Python’ on Coursera.
Organized health camps for elementary school children as part of Samsung's CSR Initiative. Organized stationary distribution for the same.
Organized earthquake and fire evacuation drills at Samsung. Contributed in drafting an emergency evacuation plan. Participated in the First Aid training organized by Fortis Healthcare.


Contains the application context subinterface for web applications, and the ContextLoaderListener that bootstraps the root web application context.


Translytical database that transforms a complex web of dynamic data into meaningful, comprehensible and traversable relationships delivered at the speed of transactions.


Normally, you instantiate cells with the concept
or cell
helper.
cell = concept("comment/cell", comment)
This gives you the cell instance. Although not encouraged, you could call multiple methods on it.
cell.(:show)
cell.(:javascript)
Normally, you will want to run the show
method, only. In controller views, this will be called automatically. However, you could do that manually as follows.
concept("comment/cell", comment).(:show)
Always invoke cell methods via call
. This will ensure that caching - if configured - is performed properly.
The #call
method also accepts a block and yields self
(the cell instance) to it. This is extremely helpful for using content_for
outside of the cell.
= cell(:song, Song.last).call(:show) do |cell|
content_for :footer, cell.footer
Note how the block is run in the global view’s context, allowing you to use global helpers like content_for
.
A cell can wrap more than one model. This can be handy to pass in additional data you need for presentation.
concept("comment/cell", comment, admin: true)
Inside the cell, the additional options are available via #options
.
class Comment::Cell < Cell::ViewModel
def show
return render :admin if options[:admin]
render
end
Class.()
Class.build (no def args)
ViewModel::cell()
Cells per default does no HTML escaping, anywhere. This is one of the reasons that makes Cells faster than Rails.
Include Escaped
to make property readers return escaped strings.
class CommentCell < Cell::ViewModel
include Escaped
property :title
end
song.title #=> "<script>Dangerous</script>"
Comment::Cell.(song).title #=> <script>Dangerous</script>
Only strings will be escaped via the property reader.
You can suppress escaping manually.
def raw_title
"#{title(escape: false)} on the edge!"
end
Of course, this works in views, too.
<%= title(escape: false) %>
clean encap, no global access, interfaces
This will instantiate each collection cell as follows.
Comment.(comment, style: "awesome", volume: "loud")


The principle of proximity is about moving things closer or farther apart to achieve a more organized look. The principle says that related items should be grouped together so that they will be viewed as a group, rather than as several unrelated elements. Audiences will assume that items that are not near each other in a design are not closely related.
>


Multi Lingual Thesaurus
The Multilingual Thesaurus Working Group (MLTWG) was merged with the Concept Definitions Task Group in 2012 to form the Geoscience Terminology Working Group.
Mission
The mission of the MLTWG was to enable the global exchange of geoscience information with the help of a common multilingual core vocabulary by developing and expanding the Multilingual Thesaurus of Geosciences.
The Multilingual Thesaurus of Geosciences (MTG) was designed to be easily accessible (including on the web), and available free of charge. The participants recognized the importance of ensuring the compatibility of national information systems with commonly accepted international standards.
Main Objectives
- Updating categories and terms
- Establishing a polyhierarchy
- Adding synonyms and related terms
- Installing the thesaurus as a web based tool
- Adding new languages
Documentation
- Facets and categories
- Requirements for the MTG structure
- Requirements for MTG terms
- Thesaurus development
- Interim Report, August 2006
- Executive summary, June 2004
Working Group Members
Marielle Arregros-Rouvreau (BRGM, France)
Claude Beaupère (BRGM, France)
Joachim Gersemann (BGR, Germany) [spokesman]
Rachel Heaven (BGS, United Kingdom)
Jan Jellema (TNO-NITG, Netherlands)
Luca Olivetta (ISPRA, Italy)
Maija Pennanen (GTK, Finland)
Sharon Tahirkheli (AGI, USA)
Sven Lundqvist (SGU, Sweden)
Caj Kortman (GTK, Finland) ) [in advisory capacity]


The main documentation index has a more detailed list of topics available.
Client side documentation contents:


⍒
)⍒ 𝕩
: Grade DownIndices of 𝕩
that would sort its major cells in descending order.
a ← 1‿2‿3 ⍒ a ⟨ 2 1 0 ⟩ (⍒a) ⊏ a ⟨ 3 2 1 ⟩
𝕨 ⍒ 𝕩
: Bins DownBinary search for each cell of 𝕩
in 𝕨
, returning the number of major cells in 𝕨
greater than or equal to that cell.
𝕨
must be sorted in descending order.
7‿5‿4‿3 ⍒ 2 ┌· · 4 ┘ 7‿5‿4‿3 ⍒ 2‿6 ⟨ 4 1 ⟩


Founded in Jackson Hole, Wyoming, Powderhorn was largely inspired by the dramatic Teton mountain range. Widely known as one of the most rugged and authentic areas for skiers and mountaineers, the ski slopes of Jackson served as the perfect testing grounds for sturdy and reliable gear.
Powderhorn is inspired by the pure nature of Jackson Hole Wyoming. Our technical apparel is built with the mindset that using natural materials provides the best balance of functionality and longevity.
If you need a jacket with almost every feature available along with being stylish, then grab the Powderhorn Teton 3 Season Jacket. This jacket comes fully equipped with an adjustable hood and waist, multiple exterior pockets and removable lightweight down vest.
For our modern, high-end products, we use sustainable materials and production processes, a choice that embodies our contribution to the responsible use of natural resources. This decision sets us apart from our competitors and creates added value in terms of social responsibility.
Our roots are in the pristine, natural world of Wyoming. For us, skiing is an emotional experience, in accord with an unspoiled landscape and its wild- life. We are proud of our roots and do our bit to ensure that this natural world remains intact for future generations.
Our products are of the highest manu-facturing quality and well worth the price. Our design underscores our mindset: "being" is more important that "seeming". Our product portfolio is not influenced by short-lived fashion; it is timeless, self-assured and down to Earth.


Our role in global initiatives and programs
5G Forum Tunisia will seek partnerships through mutual collaboration with parties and peers all over the world to promote the use of 5G.
5G Forum Tunisia will seek partnerships through mutual collaboration with parties and peers all over the world to promote the use of 5G.