Vanilla ice cream से एलर्जी दिखाने वाली कार (2000)
(cs.cmu.edu)- एक नए Pontiac मालिक ने General Motors Pontiac Division से शिकायत की कि हर शाम ice cream खरीदने के बाद, जब वह vanilla चुनता है, तभी उसकी कार स्टार्ट नहीं होती
- Pontiac के अध्यक्ष को यह पत्र संदिग्ध लगा, लेकिन उन्होंने एक engineer भेजा, और मौके पर vanilla खरीदने के बाद स्टार्ट फेल होना वास्तव में दोहराकर देखा गया
- जिन दिनों chocolate और strawberry खरीदी गई, उन दिनों कार स्टार्ट हो गई, लेकिन vanilla खरीदे जाने वाले दिन फिर फेल हुई; यह अजीब लगने वाली शर्त बार-बार सही साबित हुई
- engineer ने समय, fuel का प्रकार, आने-जाने का समय, और खरीदारी में लगा समय दर्ज किया, और पाया कि केवल vanilla को दुकान के सामने रखे अलग refrigerator से जल्दी खरीदा जा सकता है — यही आवागमन के रास्ते का अंतर था
- कारण ice cream का flavor नहीं था, बल्कि कम खरीद समय की वजह से इंजन का पर्याप्त ठंडा न हो पाना और उससे पैदा हुआ vapor lock था; यानी अजीब रिपोर्टों को भी observation और reproduction के जरिए जांचना चाहिए
Pontiac की अजीब स्टार्ट समस्या
- एक Pontiac मालिक ने General Motors की Pontiac Division को दूसरा पत्र भेजा
- परिवार हर रात खाने के बाद dessert में कौन-सा ice cream flavor खाया जाए, इस पर वोट करता था, और वह हर बार कार चलाकर दुकान से ice cream खरीद लाता था
- नई Pontiac खरीदने के बाद, समस्या केवल एक खास स्थिति में बार-बार हुई
- vanilla ice cream खरीदने पर वह दुकान से लौटकर कार स्टार्ट नहीं कर पाता था
- दूसरे flavor खरीदने पर कार सामान्य रूप से स्टार्ट हो जाती थी
- उसने माना कि सवाल मूर्खतापूर्ण लग सकता है, फिर भी उसने पूछा कि Pontiac केवल vanilla खरीदने पर ही स्टार्ट क्यों नहीं होती
मौके पर जांच और बार-बार पुनरुत्पादन
- Pontiac के अध्यक्ष ने पत्र को संदेह से देखा, लेकिन सत्यापन के लिए engineer को भेजा
- engineer रात के खाने के तुरंत बाद कार मालिक से मिला और उसके साथ ice cream की दुकान गया
- उस दिन vanilla खरीदने की बारी थी, और जब दोनों कार के पास लौटे, तो सचमुच कार स्टार्ट नहीं हुई
- इसके बाद तीन दिनों तक शर्तें बदलकर जांच की गई, और नतीजा स्पष्ट था
- पहले दिन chocolate खरीदने पर कार स्टार्ट हुई
- दूसरे दिन strawberry खरीदने पर भी कार स्टार्ट हुई
- तीसरे दिन vanilla खरीदने पर फिर स्टार्ट फेल हुई
अवलोकन रिकॉर्ड से मिला सुराग
- engineer ने यह मानने से इंकार किया कि कार को vanilla ice cream से एलर्जी है
- समस्या सुलझने तक वह आता रहा और कई तरह का data दर्ज करता रहा
- समय
- इस्तेमाल किया गया fuel
- दुकान तक आने-जाने का समय
- खरीदारी में लगा समय
- निर्णायक सुराग यह था कि vanilla खरीदने में लगने वाला समय दूसरे flavors से कम था
- दुकान की layout ही इस समय-अंतर की वजह थी
- vanilla सबसे लोकप्रिय flavor था, इसलिए उसे जल्दी उठाकर ले जाने के लिए दुकान के सामने अलग refrigerator में रखा जाता था
- दूसरे flavors दुकान के पीछे दूसरे counter पर थे, इसलिए उन्हें ढूंढने और भुगतान करने में कहीं अधिक समय लगता था
असली कारण: vapor lock
- समस्या का मूल ice cream flavor नहीं, बल्कि कम इंतजार का समय था
- engineer ने यह समझने के बाद कि असली कारण समय है, vapor lock को मूल कारण के रूप में पहचाना
- vapor lock रोज हो रहा था, लेकिन दूसरे flavors खरीदने में अधिक समय लगने के कारण इंजन पर्याप्त ठंडा हो जाता था और कार स्टार्ट हो जाती थी
- vanilla खरीदने पर खरीदारी बहुत जल्दी हो जाती थी, इंजन अभी भी गर्म रहता था, और vapor lock खत्म नहीं होता था, इसलिए कार स्टार्ट नहीं होती थी
सबक
- ऊपर से बेकार या असंभव लगने वाली समस्या भी वास्तव में सच हो सकती है
- लक्षण भले ही हास्यास्पद लगें, लेकिन अगर शर्तों को बार-बार जांचा जाए और data इकट्ठा किया जाए, तो असल कारण तक पहुंचा जा सकता है
1 टिप्पणियां
Hacker News रायें
90 के दशक के आखिर में मेरे कार्यस्थल पर भी कुछ ऐसा ही हुआ था। एक कर्मचारी का माउस दिन के कुछ खास समय पर ही रुक जाता था; सुबह ठीक रहता, दोपहर के आसपास काम नहीं करता, और बाद में फिर चलने लगता था।
अहम सुराग यह था कि बादल वाले दिनों में वह पूरे दिन ठीक रहता, लेकिन धूप वाले दिनों में वही अजीब व्यवहार दोहराता था। पता चला कि सस्ते ball mouse का प्लास्टिक केस इतना पतला था कि धूप वाले दिन सूरज की रोशनी X/Y axis sensors पर LED से ज्यादा हावी हो जाती थी, और सूरज के खिसकने से छाया बनने के बाद ही वह फिर सामान्य चलता था। शुरुआत में यह बेतुका लगा, लेकिन वजह पूरी तरह तार्किक थी।
iOS 7.1.x के लिए Pangu jailbreak के कुछ versions में लगता है कि ambient light sensor value एक खास threshold से कम होने पर boot के दौरान crash हो जाता था। असली वजह अभी भी नहीं पता, लेकिन लगता है Pangu में light sensor को छेड़ने वाला अनावश्यक code शामिल हो गया था [1]
[1] https://www.reddit.com/r/jailbreak/comments/294wob/jailbreak...
[2] https://www.reddit.com/294wob/
हर तरह की दिक्कत जांचने के बाद पता चला कि समस्या बारिश में नहीं, बल्कि घने कोहरे या हल्की फुहार के समय होती थी। cable company के technician ने जांचकर बताया कि घर के अंदर सब ठीक था, लेकिन main line से घर तक आने वाली cable में बेहद छोटा सा कट था, जिससे आसपास की नमी अंदर घुसकर connection खराब कर रही थी।
ice bin भरने पर infrared beam रुकनी चाहिए और ice making बंद हो जानी चाहिए, लेकिन धूप वाले दिन kitchen की तेज रोशनी sensor को धोखा देकर उसे लगातार बर्फ बनाने पर मजबूर कर देती है। इसलिए ऊपर कोई भी magazine रख दी है ताकि वह ठीक से काम करे।
एक दिन अचानक graphical X client app से जुड़े tests बीच-बीच में fail होने लगे, लेकिन दूसरी conditions में reproduce नहीं हो रहे थे। पता चला कि CI jobs ऑफिस में कहीं रखी desktop machines पर चल रही थीं, और किसी ने एक machine में mouse लगाकर उसे shelf पर छोड़ दिया था। machine का load बढ़ने पर fan तेज हो जाता, vibration बढ़ती और mouse बहुत थोड़ा-सा हिलता; किसी अज्ञात वजह से उसका tests पर side effect पड़ता था। जो machine वहां मौजूद भी नहीं थी, उसे SSH से diagnose कर लेना काफी संतोषजनक लगा।
पता चला कि solar panels या optimizer, inverter ऐसी radio frequency निकाल रहे थे जो garage door remote से interfere करती थी। धूप होने पर जब वे power produce कर रहे होते, interference homelink garage door opener से ज्यादा मजबूत हो जाती थी। कुछ साल पहले garage door opener अचानक ठीक से काम करने लगा, और कुछ दिन बाद पता चला कि inverter खराब हो गया था। FCC rules के हिसाब से शायद installer को इसे ठीक करना चाहिए, लेकिन installation के समय रिश्ते खराब हो गए थे, इसलिए warranty repair से निपटने के बजाय remote छोड़ देना बेहतर लगा।
सर्वर रूम वाले दौर की सुनी-सुनाई एक मज़ेदार घटना है। एक दोस्त की कंपनी का सर्वर रोज़ शाम करीब 5 बजे reboot हो जाता था, और operating system की तरफ़ से जो कुछ भी check किया जा सकता था, सब करने पर भी कारण नहीं मिला
आखिरकार उन्होंने तय किया कि उस समय सर्वर के सामने खड़े रहेंगे, और देखा कि सफ़ाई कर्मचारी कमरे में आया, server rack की power निकालकर vacuum cleaner लगाया, सफ़ाई की, और फिर server rack दोबारा plug कर दिया
कुछ camera रोज़ लगभग उसी समय restart हो जाता था; बिल्कुल वही second नहीं, बल्कि एक दिन 19:12:10, अगले दिन 2 second बाद, फिर उसके अगले दिन भी 2 second बाद—ऐसा साफ़ pattern था। पता चला कि सूर्यास्त के समय सड़क का कोई fixture camera के सामने shadow डालता था, और software उसे गाड़ी समझकर classification data इकट्ठा करने लगता था। shadow असली वाहन से बहुत धीमे चलती है, इसलिए frame से बाहर जाने से पहले memory खत्म हो जाती थी, system hang हो जाता था और watchdog उसे restart कर देता था। समय का pattern इसलिए था क्योंकि सूर्य का angle रोज़ बदलता था, जिससे shadow algorithm को हर दिन थोड़ा देर से धोखा देती थी
[0] https://old.reddit.com/r/talesfromtechsupport/comments/5yrs1...
[1] https://www.goodreads.com/book/show/3227607-the-devouring-fu...
मैं उस समय slot में एक हफ़्ते तक बैठा रहा और देखा कि lights dim हुईं और reboot हुआ। बगल वाले office का lawyer आया और उसने PC, printer और coffee pot को एक ही power strip से एक साथ चालू किया; starting current की वजह से उस circuit का voltage गिर गया जिससे server जुड़ा था। UPS था, लेकिन उस समय के consumer-grade UPS सिर्फ़ power outage संभालते थे; मैंने voltage 85V तक गिरता मापा, और असल में 95V से कम पर server reboot हो जाता था
शुक्रवार की शुरुआती दोपहर थी, गर्म और उमस भरा मौसम था और thunderstorm आने ही वाला था। करीब 16:00 बजे responsible person आया और बोला कि 17:00 बजे पूरी building की बिजली काट देंगे, इसलिए जल्दी करो। वे हर शुक्रवार energy बचाने के लिए power off कर रहे थे, और इत्तफ़ाक़ से हर शुक्रवार 16:30 बजे DB cleanup scheduled था। इसलिए बचे हुए एक घंटे में problem ठीक की, उस हफ़्ते का schedule cancel किया और DB server को manually shutdown किया। हर हफ़्ते forcefully power काटकर वे Netware server और collection software DB server में production outage बना रहे थे, और maintenance contract के तहत हर बार हमें ही ठीक करना पड़ता था। आखिर लगभग एक महीने बाद ही forced power shutdown को Saturday morning तक टाला गया, ताकि backup job पूरा होने के बाद server ठीक से shutdown हो सके
80s में मेरे brother-in-law की चलायी GM minivan याद आती है। यह car मेरे father-in-law ने दी थी, जो GM automotive engineer थे। कभी-कभी random तरीके से start नहीं होती थी और पूरा electrical system dead जैसा लगता था
brother-in-law को car के बारे में ज्यादा न जानने वाला माना जाता था, इसलिए father-in-law ने उसकी शिकायतों को गंभीरता से नहीं लिया। आखिर एक महीने के लिए car बदलकर चलाने का फैसला हुआ, और GM Technical Center parking lot में problem reproduce हो गई। आसपास जुटे GM engineers भी यह नहीं समझ पाए कि electrical system dead जैसा क्यों दिख रहा है, इसलिए brother-in-law की बात सही साबित हुई
कुछ घंटे बाद वह ऐसे start हो जाती जैसे कुछ हुआ ही न हो, इसलिए service center भी diagnose नहीं कर पाता था। बाद में off-road camping के दौरान भी start न होने लगा और जीवन पर असर पड़ने लगा। आखिर घर के driveway में start न होने की हालत में उसे एक independent garage तक tow कराया, जहाँ problem फिर reproduce हो गई। mechanic ने ECU module replacement या fuse box खुद बदलने का सुझाव दिया; ECU कई हज़ार dollars का था, लेकिन fuse box replacement labour सहित 200 dollars से कम था, इसलिए दूसरा option चुना। 6–7 साल बाद भी वही car मुख्य और इकलौती car है, और उसके बाद एक भी mechanical problem नहीं आई
GM cars के बदनाम दौर में लोगों को पागल कर देने वाली mysterious electrical problems होना पूरी तरह plausible है
लगता है कहीं कोई relay overheat होकर closed state में रह जाता था, लेकिन न मैं खुद debug कर पाया और न मेरा cousin, जो auto mechanic था, उसे ढूँढ पाया। हमने बहुत ज़ोर नहीं लगाया; जब ऐसा होता, fuse निकाल देते और अगली सुबह फिर लगा देते
starter अक्सर ठीक घूमता था, लेकिन electronics किसी अजीब state में फँस जाते थे और battery disconnect करके hard reset करने पर ही ठीक होते थे
पुराने घर में इलेक्ट्रॉनिक डिवाइसों से जुड़ी एक अजीब दोहराई जाने वाली घटना हुई थी। हफ्ते के किसी खास दिन आधी रात को, जगह पर लगे इलेक्ट्रॉनिक उपकरणों से द्वितीय विश्व युद्ध के किसी राजनीतिक भाषण की रिकॉर्डिंग जैसी आवाज़ बहुत हल्की सुनाई देती थी
आवाज़ इतनी धीमी थी कि किसी एक जगह को pinpoint करना मुश्किल था, और शब्द समझ नहीं आते थे, इसलिए लगता था जैसे कोई पुरानी रिकॉर्डिंग हर तरफ़ से एक साथ सुनाई दे रही हो। प्लग निकाल देने पर भी, घर में बिजली कट जाने पर भी यह जारी रहता था। लगा कि मैं पागल हो रहा हूं या घर में हिटलर का भूत है, लेकिन बाद में कार रेडियो पर वैसी ही चीज़ सुनकर समझ आया। एक Catholic AM radio station उसी दिन उसी समय Gregorian chant और sermon के साथ प्रसारण शुरू करता था, और घर की वायरिंग किसी तरह AM radio receiver की तरह काम कर रही थी, जिससे कुछ components वायरलेस signal पर आए audio को vibration के रूप में निकाल रहे थे
जब भी बेटा American Truck Simulator खेलता था, laptop की screen बंद हो जाती थी, और screen काली रहने के दौरान truck सड़क से बाहर चला जाता था
मैं उसी laptop पर खेलता तो ऐसा नहीं होता था, इसलिए बेटे को पूरा यकीन था कि उस पर कोई श्राप है। कई दिनों तक ऐसा दोहराने के बाद, मैंने बगल में बैठकर उसे खेलते देखा और नोटिस किया कि उसकी watch strap magnetic clasp वाली metal band थी। उसकी कलाई की position laptop के Hall sensor को trigger कर रही थी, जिससे laptop को लगता था कि lid बंद हो गई है। बेटे, मैं और मेरी पत्नी—हम सबने राहत की सांस ली कि उस पर कोई श्राप नहीं था
https://www.ifixit.com/News/33952/apple-put-a-hinge-sensor-i...
ऐसी कहानियों ने ही Car Talk को इतना मजेदार बनाया था। यह सिर्फ mechanics द्वारा car ठीक करने की बात नहीं थी, बल्कि स्थितियां इतनी अजीब और अनोखी होती थीं कि दिलचस्प लगती थीं
लंबे समय से काम कर रहे mechanics को ऐसी अजीब परिस्थितियां इतनी ज्यादा देख लेने के कारण उन्हें लगभग सामान्य मानते सुनना भी बहुत मजेदार था, और ऊपर से वे बेहतरीन storyteller भी थे
मेरे लिए सबक “बेतुकी लगने वाली समस्या भी कभी-कभी सच होती है” से ज्यादा यह है कि user की समस्या आमतौर पर सच में मौजूद होती है, लेकिन कारण diagnose करने की उसकी क्षमता पर भरोसा मत करो
पत्र में यह दावा नहीं था कि ice cream root cause है; उसने बहुत साफ किया था कि वह proximate cause है। Pontiac के president और वह “lesson” लिखने वाले व्यक्ति ने दोनों को मिला दिया होगा, लेकिन जांच करने वाले engineer ने ऐसा नहीं किया
development work के दौरान helpdesk भी कर चुका हूं, और experience यह है कि users किसी random fact को आसानी से problem का cause ठहरा देते हैं। “correlation is causation” या post hoc ergo propter hoc जैसे heuristics मदद कर सकते हैं, लेकिन अगर वे inference की जगह ले लें तो खराब है। users अपनी इस्तेमाल की चीज़ों के काम करने का तरीका नहीं जानते, इसलिए ठीक से diagnose करना मुश्किल होता है, और जो users सोचते हैं कि “मुझे ऐसी चीज़ों की थोड़ी समझ है” वे अक्सर सबसे मुश्किल होते हैं
मेरी पत्नी की car में अभी washer fluid कम है, लेकिन driving के दौरान warning सिर्फ एक खास जगह पर आती है। घर से कोई खास distance नहीं, बल्कि बिल्कुल वही location है
शुरू में लगा कि शायद कहीं जाकर लौटने में लगे समय की वजह हो, लेकिन उससे पहले 5 minutes drive की हो, 5 miles, 1 hour या 60 miles—हमेशा उसी location पर screen और sound warning आती है। एक और clue बस इतना है कि वह जगह ज्यादातर phones/carriers के लिए dead zone है। washer fluid भर देने से mystery फिलहाल dormant हो गई है, लेकिन मुझे curiosity है कि क्या सारी warnings वहीं आती हैं। लगता है जैसे उस spot पर vehicle telemetry छेड़ी जाती है, जागती है और कुछ बोलती है
sensor को “पर्याप्त liquid” से “कम” की तरफ थोड़ा धकेलने जितनी अजीब interference दे सकता है
बस container के अंदर liquid के हिलने की समस्या है। आज मैंने windshield थोड़ा साफ किया ताकि car low level indicator को लगातार on रखे
Computer Science लैब में Java असाइनमेंट करते हुए एक रात, संबंधित प्रोफेसर गुजरते हुए बोले, “अरे, उस मशीन पर तो तुम्हें किस्मत की जरूरत पड़ेगी”
वह मशीन कभी भी कोई Java प्रोग्राम चला नहीं पाती थी और शानदार तरीके से क्रैश हो जाती थी, लेकिन C++ या Python ठीक चलते थे. शुरुआत में भरोसा न करने वाले प्रोफेसर का प्रोग्राम भी उस मशीन को क्रैश करा गया. एक तकनीशियन और प्रोफेसर ने करीब 2 हफ्ते तक जांच की, तो पता चला कि JVM हर बार शुरू होते समय integer 12 को उसी RAM address पर allocate करता था, और उस hardware address वाला RAM chip खराब था. जब भी उस address पर allocate करने की कोशिश होती, क्रैश हो जाता, और खराब RAM stick बदलते ही समस्या तुरंत हल हो गई
https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
निष्कर्ष का spoiler नहीं दूंगा. यह लंबी और घुमावदार debugging यात्रा है, पढ़ने लायक. HN discussion:
https://news.ycombinator.com/item?id=15845118
यह कहानी confounding variable का एक मजेदार उदाहरण है
causal inference में confounding variable वह variable होता है जो dependent variable और independent variable दोनों को प्रभावित करके एक नकली association बनाता है. यह correlation भर से समझाया नहीं जा सकने वाला causality concept है, और “correlation का मतलब causation नहीं होता” के महत्वपूर्ण quantitative कारणों में से एक है
https://en.wikipedia.org/wiki/Confounding
statistical model में लिखें तो इसे
S = f(H, I, T)जैसा देखा जा सकता है.Sयह है कि कार start होती है या नहीं,Hengine temperature है,Iचुनी गई ice cream का type है, औरTice cream खरीदने में लगा समय है. अगरTकम हो, तो engine ज्यादा गर्म रहता है और vapor lock के प्रति अधिक vulnerable हो जाता है, जिससेSपर असर पड़ता है; और vanilla ice cream की location उसे जल्दी खरीदना संभव बनाती है, इसलिए वहIसे भी जुड़ता है. इसलिएIऔरSके बीच एक नकली relationship बन जाता हैTकाIपर असर होने के बजायIकाTपर असर नहीं होता? क्योंकि ice cream का type ही store के अंदर लगने वाला समय तय करता है